Как мне хранить пароль соль? - PullRequest
11 голосов
/ 28 марта 2012

Используя PHP, я кодирую пароли, используя функцию hmac с алгоритмом sha256.В чем я не уверен, так это в том, как правильно хранить соль.

Весь смысл хеширования пароля в том случае, если хакер получает доступ к базе данных.Если я храню соль в БД в той же строке, что и хешированный пароль, разве это не похоже на то, что я передаю хакеру «секретный код»?Я открываю дверь с замком и передаю злоумышленнику ключ.

Может кто-нибудь объяснить мне, как они собираются хранить свою соль?

Ответы [ 3 ]

16 голосов
/ 28 марта 2012

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

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

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

3 голосов
/ 28 марта 2012

Я бы выбрал хранение соли вместе с идентификатором алгоритма хеширования и самим хэшем.

Вот почему:

Обычно доступ к базе данных ограничен localhost или некоторым предварительно заданным диапазоном IP-адресов. Это означает, что для того, чтобы хакер получил доступ к вашей базе данных, он / она должен был бы скомпрометировать файловую систему вашего сервера (либо получив прямой доступ, либо внедрив скрипт). Или выполнить SQL-инъекцию.

В первом случае это означало бы, что если кто-то получит доступ к вашим солям в БД, он / она сможет так же легко прочитать их из вашего источника PHP-файлов.

Последняя причина может быть просто предотвращена путем использования подготовленных операторов с PDO или MySQLi . Вам больше не следует использовать старые функции mysql_* в качестве API. Они больше не поддерживаются, и процесс устаревания уже начался .

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

Если вы используете PHP 5.5+, вы должны вместо этого использовать новый API паролей: http://php.net/password

2 голосов
/ 28 марта 2012

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

...