Поэтому я ищу для разработки системы безопасности php с высокой степенью защиты. Я решил начать с конца входа / сеанса. Я хотел бы, чтобы кто-то взглянул на мой план и сообщил мне о лазейках и недостатках безопасности.
Это мой первый попыток создать систему на таком уровне, если вы обнаружите проблему, можете ли вы отправить мне ресурсы, чтобы помочь мне исправить это.
Подключение к базе данных * Я буду использовать MYSQL, поэтому ваше стандартное соединение с базой данных будет храниться в файле вне корней сайтов.
Регистрация * Регистрация будет простой формой, я использую функцию, хранящуюся во внешнем файле, для дезинфекции ввода и защиты от SQL Injection
// A function to sanitize input for data being input into a database function sanitizeinput($rawinput) { $sanitizedinput = mysql_real_escape_string($rawinput); return $sanitizedinput; } Есть ли что-то, что мне нужно для этой функции, чтобы ее еще больше укрепить?
Пароль – это хэширование с использованием SHA-512 или BCrypyt, я провел небольшое исследование и увидел, что многие люди говорят, что MD5 уже недостаточно безопасен, я хочу обеспечить максимальную безопасность, поэтому, что я должен использовать для хешировать пароли.
Я также добавил произвольно сгенерированную соль, используя следующий фрагмент, который был добавлен к фронту хэшированного пароля, а затем повторно воспроизведен. Затем соль хранится в базе данных в текстовом формате, следует ли мне зашифровывать это для дополнительной безопасности?
Когда пользователь отправляется на вход в свой введенный пароль, будет хеширован, соль из базы данных добавляется и повторно отображается, а затем сравнивается с паролем, хранящимся в базе данных.
Если будет создан пароль, соответствующий сеанс будет заблокирован на один IP-адрес и пользовательский агент. После этого сеанс истечет через короткое время. Сессия будет использоваться только для хранения токена входа, имя пользователя и пароль, конечно, не будут храниться в сеансе.
Когда пользователь регистрируется в токене, он будет сохранен в базе данных с присвоенным им именем пользователя, чтобы мы могли безопасно извлекать данные пользователей из базы данных с помощью токена, не рискуя хранить его в сеансе.
Если пароль неверен, пользователь не будет входить в систему … duh, я также буду применять защиту грубой силы, после трех попыток пользовательский IP-адрес и агент пользователя будут заблокированы в течение 15 минут и после десяти неудачных попыток заблокированы в брандмауэре.
Я чувствую, что что-то забываю, но я не могу наложить на него свой палец.
Любая помощь или совет будут высоко оценены.
Я никоим образом не специалист по этому вопросу, но сначала переключитесь на PDO для подключения к mySQL. Это кажется немного сложнее, но защищает вас на 100% от тех, кто пытается делать инъекции sql, ЕСЛИ ИСПОЛЬЗУЕТСЯ ПРАВИЛЬНО. Для шифрования я использовал это для генерации случайной соли для каждого пользователя:
function generateSalt($length, $chars) { $randString = ''; $charLength = strlen($chars); for($count = 0; $count < $length; $count++) { $randString .= substr($chars, mt_Rand(0, ($charLength-1)), 1); } return $randString; }
Если вы кормите его строкой, она выплевывает соль заданной длины из символов этой строки. Тогда я считаю, что использовал blowfish из-за того, что его нелегко взломать.
Вы считали уязвимость XSS? Мне еще и не нужно это делать. Убедитесь, что пользователи не вставляют html или javascript-код в вашу базу данных, которые могут отображаться где-то на странице позже.
Удачи.
EDIT: Вот что я использую для "хеширования"
$cryptOptions = '$2y$10$' . $salt . '$'; $hashedPassword = crypt($password1, $cryptOptions);
Почему вы храните соль в базе данных? Предположим, кто-то получает доступ к вашей базе данных – у него будут пароли и соль (ы). Если бы у вас была твоя соль в твердом переплете или где-то еще, у него просто были бы хешированные пароли. Если злоумышленник получает полный доступ к вашим системам, это не имеет значения.
Кроме того, вы будете использовать https для входа в систему?
Предполагая, что у вас несколько соединений с базой данных, и у них разные кодировки – вы должны передать правильную ссылку на вашу функцию дезинфицирующего средства. Кстати, в чем преимущество переноса mysql_real_escape_string с другой функцией, которая не добавляет вещь (но фактически ограничивает фактическую функцию)? Я бы посоветовал вам использовать PDO.
Реализован аналогичный прототип несколько месяцев назад в Java.
Из того, что я вижу, это похоже на то, что у меня было. Некоторые вещи, которые я сделал (или, по крайней мере, планирую делать), которые я не вижу из вас объяснения
Надеюсь, это даст вам дополнительные идеи.
Извиняюсь, я не могу прокомментировать сообщение m02ph3u5, поэтому я должен опубликовать еще один ответ. Хранение солей в базе данных является полностью стандартным. Причина, по которой существуют соли, заключается в том, чтобы предотвратить грубое форсирование радужными столами. Таблицы Rainbow представляют собой предварительно вычисленные хэши, которые позволят быстро взломать все пароли в базе данных. С солями, даже известными злоумышленнику, радужный стол не может быть предварительно вычислен. Это означает, что людям приходится перебирать каждый пароль. Это хорошо, потому что если вы используете такой алгоритм, как blowfish, тогда взломать сотни паролей становится непрактичным.
Это не способ сделать пароли невозможными для взлома. Это способ сделать непрактичным взломать ВСЕ пароли.
EDIT: Если они получат доступ к вашему db, у них будет только ваш хешированный пароль и соли. Они по-прежнему требуют пароль обычного текста.
EDIT2: Итак, идея в том, что у них есть доступ к сайту, поэтому единственное, что мы хотим сделать в этот момент, – это защитить пароль. Обычно люди повторно используют пароли. Хеширование – это просто защита этих людей.