Мнения о двойной аутентификации с использованием соли для учетных записей пользователей с низкой чувствительностью?
В настоящее время я работаю над веб-проектом, требующим учетных записей пользователей. Приложение CodeIgniter находится на стороне сервера, поэтому я использую Ion Auth в качестве библиотеки аутентификации.
Я уже писал систему аутентификации раньше, где я использовал 2 соли для защиты паролей. Одним из них была общесерверная соль, которая находилась в качестве переменной среды в файле .htaccess, а другим была случайно сгенерированная соль, которая была создана при регистрации пользователя.
Это было метод, который я использовал в этой системе аутентификации для хеширования пароля:
$chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
//create a random string to be used as the random salt for the password hash
$size = strlen($chars);
for($i = 0; $i < 22; $i++) {
$str .= $chars[rand(0, $size - 1)];
}
//create the random salt to be used for the crypt
$r_blowfish_salt = "$2a$12$" . $str . "$";
//grab the website salt
$salt = getenv('WEBSITE_SALT');
//combine the website salt, and the password
$password_to_hash = $pwd . $salt;
//crypt the password string using blowfish
$password = crypt($password_to_hash, $r_blowfish_salt);
Я понятия не имею, есть ли в этом дыры или нет, но, несмотря на это, я перешел на Ion Auth для более полного набора функций для использования с CI.
Я заметил, что Ion использует только одну соль как часть своего механизма хеширования (хотя и рекомендует установить encryption_key для защиты сеанса базы данных.)
Информация, которая будет храниться в моей базе данных, это такие вещи, как имя, адрес электронной почты, местоположение по стране, некоторые заметки (которые рекомендуется не содержать конфиденциальной информации) и ссылка на учетную запись Facebook, Twitter или Flickr. Исходя из этого, я не уверен, что мне необходимо иметь SSL-соединение на защищенных страницах моего сайта.
Мой вопрос в том, есть ли особая причина, по которой только 1 соль используется как часть библиотеки аутентификации ионов? Подразумевается ли, что я пишу свою собственную дополнительную посолку перед функциональностью это обеспечивает, или я что-то упускаю?
Кроме того, стоит ли вообще использовать 2 соли, или как только злоумышленник получит случайную соль и хэшированный пароль, все ставки все равно будут отменены? (Я предполагаю, что нет, но стоит проверить, беспокоюсь ли я ни о чем...)
2 answers
Это потому, что Ion_Auth использует bcrypt - так что вам, как правило, не нужно делать намного больше.
Кроме того, вы можете настроить "random_rounds", что похоже на случайное посоление (в определенной степени) в конфигурации.
Редактировать: вы можете просмотреть этот поток SO для получения более подробной информации о bcrypt и других типах шифрования
Аргумент о том, что кто-то может каким-то образом найти способ ввести код, или вы по ошибке оставляете каталог открытым для просмотра, или кто-то находит инъекционный взлом и может увидеть файл системной соли или данные пользователя, не является убедительной причиной для использования двойных солей. Если что-то из этого, действительно, вам придется беспокоиться больше, чем о списке засоленных и зашифрованных паролей пользователей!
Все это, как говорится, двойной солевой раствор действительно намного безопаснее, особенно если есть шанс, что кто-то другой кроме того, вы увидите системную соль в своем коде. Подумайте о ситуации, когда, возможно, уходит подрядчик или коллега. Если они знают соль и используемый алгоритм/алгоритм посола, они могут создавать радужные таблицы и использовать их против вашего сайта. Добавление второй случайной соли в запись пользователя защищает от этого.
Все дело в том, чтобы взвесить ценность того, что ваша безопасность против количество разумных усилий, которые кто-то должен был бы предпринять, чтобы получить то, что вы хотите. Также, просто не быть полностью небрежным, вообще не используя соли или вообще не шифруя, к сожалению, лучше, чем во многих других менее безопасных местах, где хранятся наши основные данные. Если это не кредитная информация, медицинские записи, номера социальных сетей и просто информация о пользователе (электронная почта, адрес и т. Д.), И вы не планируете когда-либо вводить эти данные, вероятно, достаточно одной соли. Если вы не можете принять это решение со 100 % уверенностью сейчас, сделайте ошибку на стороне более безопасного варианта.