Соленый пароль безопасности

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

Легче подобрать пароль с известной солью или чем-то еще? Или хакеры делают свои собственные радужные таблицы, когда знают соль?

С уважением


person Tom Broucke    schedule 04.07.2012    source источник
comment
возможный дубликат безопасного хэша и соли для паролей PHP   -  person John Conde    schedule 04.07.2012
comment
@JohnConde На самом деле это не дубликат. Этот вопрос касается преимущества использования разных солей для каждого пароля.   -  person Styxxy    schedule 04.07.2012
comment
В последнее время это становится популярной темой, но все согласны с тем, что пароли с солью и использование криптографического хэша недостаточно. Вместо этого исследуйте использование функций деривации ключей.   -  person Leigh    schedule 04.07.2012
comment
@Leigh: Любое дальнейшее чтение для этого?   -  person Creshal    schedule 05.07.2012
comment
@Creshal Вступительный абзац для PBKDF2 в Википедии резюмирует, почему KDF сильнее. В документе SCrypt также есть полезная (более техническая) информация для создания более надежных KDF.   -  person Leigh    schedule 05.07.2012


Ответы (3)


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

Используйте индивидуальные хэши и дорогой алгоритм (bcrypt, scrypt).

person Creshal    schedule 04.07.2012

Когда вы даете каждому паролю свою собственную индивидуальную соль, между каждой солью в каждом пароле нет общей связи. Таким образом, даже если «хакер» взломает один пароль, у него не будет соли для любого другого пароля.

Когда дело доходит до использования PHP и соления ваших паролей, вы должны использовать медленное шифрование, такое как crypt. Чем быстрее вы что-то зашифруете, тем быстрее «хакер» сможет найти способ его расшифровать.

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

person Marcus Recck    schedule 04.07.2012
comment
В ответ на ваш первый абзац: даже если он знает соль, ему все равно нужно дехэшировать пароль, что «невозможно», потому что хеширование необратимо? - person Tom Broucke; 04.07.2012
comment
Он мог взломать его, используя случайную соль + пароль, используя метод шифрования, который вы использовали. Вот почему Крешал и я предлагаем использовать метод медленного шифрования. - person Marcus Recck; 04.07.2012
comment
@TomBroucke Брут-форс на несколько порядков быстрее, когда есть только один хеш. Вам нужно только один раз вычислить каждый хэш с солью. С отдельными солями для каждого пользователя вам придется повторять весь процесс для каждого пользователя. Я не могу придумать более простой способ увеличить сложность. - person Creshal; 05.07.2012

Хорошо, давайте проясним одну вещь: соление не имеет ничего общего с радужными столами. да. Повтори. Соление не имеет ничего общего с радужными столами.

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

В случае радужной таблицы использование соли означает, что вся таблица становится недействительной.

Но есть и другие способы аннулирования всей таблицы. К каждому паролю можно добавить статическую строку (которая не является солью). Это победит радужные столы...

Настоящий враг

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

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

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

Соли должны быть случайными и для каждого пользователя.

person ircmaxell    schedule 21.06.2013