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

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

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

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

HASHPW = PW.RANDOMNUMBER

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

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

Спасибо!

Ответы [ 5 ]

19 голосов
/ 13 сентября 2009

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

15 голосов
/ 13 сентября 2009

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

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

2 голосов
/ 13 сентября 2009

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

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

1 голос
/ 13 сентября 2009

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

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

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

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

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

1 голос
/ 13 сентября 2009

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

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

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

...