хеш — PHP password_hash () / bcrypt
Я проверяю хэш-алгоритм bcrypt.
Мой первый тест с password_hash ():
echo password_hash("123", PASSWORD_BCRYPT, array( "salt" => "1234567890123456789012" ));
echo password_hash("123", PASSWORD_BCRYPT, array( "salt" => "1234567890123456789012xxxxxxxxxxxxxxx" ));
Оба вернут ‘$ 2y $ 10 $ 123456789012345678901uiaLpJxTpf6VbfI5NADlsRsfvEm6aq9C’.
- Какого черта соль хранится внутри хеша? Это не имеет никакого смысла для меня. Злоумышленник, который получает хэши из базы данных, не может ничего с ними сделать, если он не знает соли.
- Почему я получаю один и тот же хэш с двумя разными солями? Только первые 22 символа, используемые для соли, переданы функции?
Большое спасибо!
Решение
Соль не является секретом, она обычно хранится в базе данных вместе с хешем и может также храниться непосредственно в хеше, например password_hash делает.
Соль создает уникальность, поэтому хеш не может быть легко взломан такими вещами, как радужные таблицы или словари, он на самом деле не повышает безопасность, кроме того, что делает хеш более уникальным, поэтому запуск словаря или таблицы для хеша не совпадает, потому что он также включает в себя соль.
Если вы опустите соль, случайная соль будет сгенерирована password_hash() для каждого хэша пароля. Это предполагаемый режим работы, и вы не должны поставлять свои собственные соли.
PHP7 фактически выдаст предупреждение о том, что использование соли не рекомендуется.
Переданная соль должна содержать не менее 22 символов, но большинство базовых алгоритмов, таких как bcrypt, не используют всю соль, см. этот ответ подробнее об этом
Другие решения
Соли — это не то, что вы должны стремиться сохранить в тайне. Их защита эффективна, даже если она известна. https://crackstation.net/hashing-security.htm
Соль не должна быть секретной. Простое рандомизирование хешей приводит к тому, что таблицы поиска, таблицы обратного просмотра и радужные таблицы становятся неэффективными. Злоумышленник не будет заранее знать, какой будет соль, поэтому он не может предварительно вычислить таблицу поиска или радужную таблицу. Если пароль каждого пользователя хешируется по-разному, атака с использованием таблицы обратного просмотра также не будет работать.
Поскольку вы, похоже, используете фиксированное значение соли, обратите внимание на следующее:
Распространенной ошибкой является использование одной и той же соли в каждом хеше. Либо соль жестко запрограммирована в программе, либо генерируется случайным образом один раз. Это неэффективно, потому что если два пользователя имеют один и тот же пароль, они все равно будут иметь одинаковый хэш. Злоумышленник по-прежнему может использовать атаку с использованием таблицы обратного просмотра для одновременного запуска атаки по словарю на каждый хэш. Им просто нужно применить соль к каждому паролю, прежде чем они его хешируют. Если соль жестко закодирована в популярный продукт, для этой соли могут быть созданы справочные таблицы и радужные таблицы, чтобы было легче взломать хеши, сгенерированные продуктом.
Я бы предложил использовать password_hash без его необязательных параметров. Функция по умолчанию создана для обеспечения высокой степени безопасности и, указав собственный алгоритм и параметры, вы потенциально ослабляете ее функцию.
В соответствии с PHP документация:
предосторожность Настоятельно рекомендуется не создавать собственную соль для этой функции. Он автоматически создаст безопасную соль, если вы ее не укажете.
редактировать: Вот почему хранить соляную тайну в bcrypt бессмысленно.
в эта почта, в 8-символьном пароле имеется 3 025 989 069 143 040 возможных комбинаций. Как правило, вам нужно настроить коэффициент работы bcrypt, чтобы хэшировать пароль за 0,1 секунды. Это означает, что расчет всех возможностей занимает 302,598,906,914,304 секунд. Это 9 588 тысячелетия.
detector