Хеш пароля и засолка - это хороший метод?

Question

Я проводил небольшое исследование или прибегал к поиску различных методов обработки хеширования и подсчета паролей и наткнулся на эту интересную ссылку:

http://phix.me/salt/

Теперь, по сути, предлагается создать две пользовательские функции: одну для хеширования и одну для проверки хеша.

Соль псевдослучайна, но на самом деле основана на пароле (мне кажется плохим?).

Функция хеширования также псевдослучайно "разбрызгивает" соль в строке хеша.

Функция проверки хэш-функции отменяет разбрызгивание соли, после чего происходит фактическая проверка хеш-функции.

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

Мне нравится идея, что соль неочевидна и что она также не должна основываться на некоторой, как мы надеемся, непротиворечивой ценности, такой как имя пользователя, идентификатор пользователя, дата рождения и т. Д., Но, как я уже сказал, у меня есть сомнения относительно реализация.

Итак, каковы мнения и идеи людей о "наилучших подходах"?

Answer 1

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

Получение соли из пароля полностью упускает из виду.

Answer 2

Цель соли - сделать использование радужного стола чрезмерно дорогим, поэтому попытка 1 в значительной степени решает проблему правильно. Использование соли для пароля устраняет изменчивость, которая побеждает радужные таблицы, и пытаться скрыть ее в поле хешированного пароля просто бессмысленно.

Answer 3

Я задавал аналогичный вопрос ранее. Консенсус был такой:

Неважно, как вы солите, пока вы:

1. Соль перед хешем
2. Использовать случайную соль, уникальную для пароля
3. Используйте достаточно большое количество соли, чтобы сделать радужные столы непосильными.

Вы даже можете хранить свою соль рядом с вашими хешированными паролями и чувствовать себя чертовски уверенно.

Лично я нахожу, что GUID (в строковом формате) отлично работают для Salts. Они генерируют строку кода для генерации и в строковом формате более чем достаточно велики, чтобы радужные таблицы вычислялись тысячелетиями.

Answer 4

Ранее задавалось много похожих вопросов:

• Безопасный хэш и соль для паролей PHP
• Является ли «двойное хеширование» паролем менее безопасным, чем одноразовое хеширование?
• Какой алгоритм я должен использовать для хэширования паролей в моей базе данных?

Это должно дать вам представление о том, как хэшировать пароли.

Answer 5

(отредактированный ответ, потому что изначально я неправильно прочитал статью и подумал, что он просто смешивает соль с несоленым хешем)

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

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

Если вы хотите действительно надежно хранить свои пароли, отойдите от MD5 и даже SHA1 и двигайтесь в сторону хэш-функции медленнее . Это отличная статья на эту тему: Достаточно с таблицами Rainbow: что нужно знать о безопасных схемах паролей

Answer 6

Мне кажется, что я просто добавляю обфускацию , , а не безопасность , к (как Чед Бёрч указал неправильно понятый ) соленому хеш-методу. 1007 *

Answer 7

Я не могу просмотреть ссылку в исходном вопросе (веб-сайт просто возвращает ошибку 404 not found), но метод, описанный в этом вопросе, не использует соленый хеш.

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

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

Answer 8

Интересно, что это не просто запутывание, не больше безопасности , но на самом деле запутывание, меньше безопасности , потому что «Попытка 4» хороша только в той мере, в которой она использует функцию CRC32 (CRC32 передается ТОЛЬКО пароль, а не пароль + соль) - это падение.

В соответствии с постом Чада, чтобы взломать «Попытку 4», все, что нужно сделать, это загрузить пароли CRC32, а затем поменять функцию, которую он закодировал, оставив вам соленый хэш md5 и соль (которую вы затем протестируете). для действительности). Просто протестируйте эту пару, вычислив md5 (пароль + соль) (где пароль - это пароль, который вы пытаетесь), а соль - это соль, которую вы вычислили путем обращения алгоритма. Если md5 соответствует первым 32 символам хэша, вы взломали пароль.

«Попытка 4» в некоторых отношениях хуже, чем «Попытка 1», поскольку она так же хороша, как и наихудшая функция, вызываемая во всей подпрограмме, в данном случае CRC32 (пароль).