Если я делаю СОЛЬ случайным для каждого пользователя, как я могу их аутентифицировать?

Я читал о преимуществах соления и хэширования паролей, но одна вещь еще ускользает от меня...

Когда я предоставляю случайную соль для каждого пользователя, как узнать, чем была соль, когда я пытаюсь аутентифицировать их для входа?

так что если я...

HASHPW = PW.RANDOMNUMBER

Я мог бы хранить случайное число в базе данных, но это, похоже, убило всю цель добавления соли. Разве это не так? Я мог бы также использовать не случайное число для каждой соли, но тогда это также убивает точку соли, потому что, если они выясняют это, у них есть все мои пароли пользователей...

Я только начал изучать PHP и MySQL, и абстрактные вещи, подобные этому, меня смутили.

Спасибо!

Ответ 1

Это не побеждает цель уникальной соли, чтобы ее сохранить. Точка уникальной соли - защитить весь ваш репозиторий от атаки, а не от конкретного отдельного пользователя. Если злоумышленник компрометирует вашу базу данных и достаточно определен, чтобы взломать определенную учетную запись пользователя, они будут. Мы ничего не можем с этим поделать. Но им придется потратить слишком много времени на компьютерное время - достаточно, чтобы было нецелесообразно тратить столько времени на каждого пользователя, таким образом защищая всех ваших пользователей. Контрастируйте это с использованием той же соли для всех пользователей - как только у злоумышленника будет соль, те же таблицы/процессы могут повторно запускаться против каждого пользователя за относительно короткое время.

Ответ 2

Соль генерируется случайным образом для каждого пользователя, но она сохраняется где-то в базе данных. Вы просматриваете соль для конкретного пользователя и используете ее для аутентификации пользователя.

Дело в том, что для каждого пользователя соль различна, вы не можете использовать готовый словарь хешей для сопоставления хешированных паролей для очистки текста (rainbow attack).

Ответ 3

Соль не позволяет кому-либо получить копию вашей зашифрованной базы паролей и одновременно установить автономную атаку на все пароли. Он не предотвращает атаки на один пароль.

Вам может понравиться читать оригинальную статью безопасности паролей Unix. Это очень хорошая работа, объясняющая, что такое соль, и почему мы имеем их: http://portal.acm.org/citation.cfm?id=359172

Ответ 4

при создании хешированного пароля вы должны использовать "двойную" соль

Создайте соль (случайный md5 или sha1), затем используйте формат, похожий на sha1 ( "- $password - $salt--" ), а затем сохраните хешированный пароль и соль в базе данных.

Затем при аутентификации вы воссоздаете хэш из - $pass - $salt-- string и сравниваете его с проходом, хранящимся в db.

Ответ 5

Для каждого пароля вам не нужна отдельная соль.

Цель соления - противостоять радужным столам - вы конвертируете пароль кандидата в новую строку, в которой есть соль; так как соль - это какая-то частная строка, которую вы только обладаете, зная, что хэш солевого пароля не поможет злоумышленнику, у которого есть пробег радужного стола.

Умный злоумышленник может попытаться создать пользовательскую таблицу радуги только для вашей службы, создав учетную запись и изменив свой пароль, чтобы узнать, что такое хэш. Если соль одинакова для каждого пользователя, тогда, когда он видит, что хеш "xyz123" соответствует "яблоку", и замечает, что другой хэш-хэш также "xyz123", он может заключить, что этот пароль пользователя "яблоко". Это тот момент, когда большинство людей решает сохранить уникальную соль для каждого пользователя.

Однако это необязательно. У вас уже есть уникальная строка для каждого пользователя - имя пользователя. Это не секрет, так что это не соль. однако конкатенация имени пользователя и глобальной секретной соли является как секретной, так и уникальной. Если вы храните хэш (имя пользователя + соль + пароль), вам нужно знать только одно значение глобальной соли во время поиска.

(это правда, что это создает больший риск, если кто-то утечки одной глобальной соли, но это метод, который стоит рассмотреть).