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