Соль пароля: дополнительные рекомендации

Question

Как и большинство программистов, я не специалист по криптографии, но я понимаю основы. Однако, немного знаний может быть опасной вещью, как отмечено в сообщении Джеффа в блоге . Имея это в виду, я понимаю цель значения соли, но мне нужно немного помочь понять, как использовать значения соли.

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

Answer 1

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

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

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

Answer 2

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