Как хранить пароль salt?
используя PHP, я кодирую пароли, используя функцию hmac с алгоритмом sha256. В чем я не уверен, так это в том, как правильно хранить соль.
весь смысл хэширования пароля заключается в том, что хакер получает доступ к базе данных. Если я храню соль в БД в той же строке, что и хэшированный пароль, разве это не так же, как я передаю хакеру "секретный код"? Я ставлю дверь с замком и вручаю ключ незваному гостю.
может кто-нибудь пожалуйста, объясните мне, как они стали хранить соль?
3 ответов
положить соль в руки злоумышленника, который украл вашу базу данных на самом деле не проблема. Объединение соли с исходным паролем в хэш пароля защищает от злоумышленника, используя "радужные таблицы" миллионов известных и хорошо известных хэшей паролей для получения паролей некоторые украденных идентификаторов пользователей.
хеширование пароля и соли вместе делает его на много порядков сложнее взломать даже один пароль, на том основании, что соль аннулирует хэши паролей, известные в таблице rainbow. Поэтому, даже если соль известна злоумышленнику для каждого из ваших пользователей, это означает, что для взлома любого отдельного пользователя злоумышленник должен вычислить целую новую таблицу rainbow только для этого пользователя, которая сочетает соль пользователя с остальными паролями, известными в таблице rainbow, с которой они начали.
солить пароль не делает его невозможно взломать пароль, но гораздо сложнее. Например, злоумышленник может нацелиться на небольшое подмножество ваших пользователей с хэшем и солью в руке, и это еще одна причина поощрять надежные пароли, которые с меньшей вероятностью появятся в радужной таблице.
Я бы предпочел хранить соль вместе с идентификатором алгоритма хэширования и самим хэшем.
вот почему:
обычно доступ к базе данных ограничен localhost или некоторый предопределенный диапазон IP-адресов. Это означает, что для того, чтобы хакер получил доступ к вашей базе данных, ему / ей нужно будет скомпрометировать файловую систему ваших серверов (либо получив прямой доступ, либо введя скрипт). Или выполните SQL-инъекцию.
в первом случае это это означает, что если кто-то получил доступ к вашим солям в БД, он/она может легко прочитать их из вашего источника PHP-файлов.
последняя причина может быть просто предотвращена с помощью подготовленных заявлений с помощьюPDO или MySQLi. Вы не должны использовать старый mysql_* функции как API больше. Они больше не поддерживаются и процесс устаревания начало уже.
даже если кто-то получает его / ее руки на вашей БД, это не все, что проблематично. Если вы используете crypt() функция для создания хэшей с хорошими алгоритмами (рекомендуется CRYPT_BLOWFISH), то взлом даже одного пароля может быть чрезвычайно длинным (в масштабе лет). К этому времени вы можете легко отправлять уведомления "изменить пароль" пользователям и блокировать всех, кто этого не сделал.
если вы используете PHP 5.5+, вы должны вместо этого использовать новый API паролей: http://php.net/password
соль предназначена для того, чтобы быть открытым текстом и сразу доступным. Хэш пароля совершенно необратим, но он атакован словарем. Таким образом, соли достаточно, чтобы добавить несколько порядков величины, чтобы нарушить атаку словаря. Предоставление соли не должно ухудшать безопасность хэшированного пароля.