Хэш пароля и соление - это хороший метод?
Я делал небольшое исследование или гуглил для различных методов обработки хэширования паролей и соления и наткнулся на эту интересную ссылку:
теперь, по сути, это предлагает создание двух пользовательских функций, одна для хэширования и одна для проверки хэша.
соль псевдослучайна, но на самом деле основана на пароле (поражает меня как плохо?).
функции хэширования также псевдо случайным образом" посыпает " соль среди хэш-строки.
функция проверки хэша отменяет посыпку соли, а затем происходит фактическая проверка хэша.
теперь я знаю, что уникальные соли для каждого хэша пароля = хорошо, но также и то, что логика хэширования паролей и создания соли, хранящейся в функции db, может = плохо.
Мне нравится идея, что соль не очевидна и что она также не должна основываться на некоторых, надеюсь, последовательных значение, такое как имя пользователя, идентификатор пользователя, дата рождения и т. д., Но, как я уже сказал, У меня есть сомнения относительно реализации.
Итак, каковы мнения и идеи людей о "лучших решениях подхода"?
8 ответов
цель соли состоит в том, чтобы использовать Радужный таблице непомерно дорого, поэтому попытка 1 в значительной степени решает проблему правильно. Основывать соль на пароле исключает изменчивость которая побеждает таблицы радуги, и попытка спрятать ее в хэшированном поле пароля как раз бессмысленна.
на соль не должна быть тайной. он должен быть непредсказуемым для данного пароля.
вывод соли из пароля полностью пропускает точку.
попросил аналогичный вопрос раньше. Консенсус был таков:
не имеет значения, как Вы соль, пока вы:
- соль перед хэшем
- используйте случайный соль уникальный пароль
- используйте достаточно большую соль, чтобы сделать радужные таблицы запретительными.
вы даже можете хранить соль рядом с хэшированными паролями и чувствую себя чертовски уверенно.
лично я нахожу GUIDs (в string format) отлично подходит для солей. Они берут строку кода для генерации и в строковом формате достаточно велики, чтобы сделать радужные таблицы тысячелетиями для вычисления.
было задано много подобных вопросов:
- Безопасный хэш и соль для паролей PHP
- является ли" двойное хеширование " паролем менее безопасным, чем просто хеширование его один раз?
- какой алгоритм я должен использовать для хэширования паролей в мою базу данных?
Это должно дать вам представление о том, как хэшировать пароли.
(отредактированный ответ, потому что я неправильно прочитал статью и думал, что он просто смешивает соль вместе с несоленым хэшем)
его методы кажутся прекрасными, они будут работать, но на самом деле они не "лучше", чем обычные методы соления. Это просто попытка сделать безопасность неизвестностью, это не лучше, чем составить свой собственный случайный метод "хэш-скремблирования" и надеяться, что злоумышленник не поймет этого.
на самом деле, это может быть во многих случаях злоумышленнику довольно легко понять эти функции. Если сайт имеет публичную регистрацию, злоумышленник может повторно зарегистрировать учетные записи с известными паролями, а затем использовать известные хеши md5 для этих паролей для обратного проектирования алгоритма скремблирования паролей. Я мог бы сделать это очень легко, даже глядя на результат его "попытки 4".
Если вы хотите сохранить свои пароли действительно безопасно, уйти от MD5 и даже SHA1 и перейти к соленый,медленнее хэш-функция. Это отличная статья на эту тему:Достаточно Радужных Таблиц: Что Вам Нужно Знать О Безопасных Схемах Паролей
Это кажется мне просто добавить обфускации, больше нет безопасности, к (как указал Чад Берч недопонял) соленые хэш-метод.
интересно, что это не просто запутывание, не больше безопасности но на самом деле обфускации, меньше безопасности потому что "попытка 4" так же хороша, как функция CRC32, которую она использует (CRC32 передается только пароль, а не пароль+соль) - это падение.
согласно сообщению чада, чтобы взломать "попытку 4", Все, что нужно сделать, это загрузить CRC32 пароли, а затем отменить функцию, которую он закодировал, оставив вас с соленым хэшем md5 и солью (которая затем вы проверите правильность). Просто проверьте эту пару, вычисляя md5 (пароль+соль) (где пароль-это пароль, который вы пытаетесь), а соль-это соль, которую вы рассчитали, изменив алгоритм. Если md5 равен первым 32 символам хэша, вы взломали пароль.
"попытка 4" хуже, чем" попытка 1", в некоторых отношениях, так как это так же хорошо, как худшая функция, называемая во всей подпрограмме, в этом случае CRC32(пароль).
Я не могу просмотреть ссылку в исходном вопросе (веб-сайт просто возвращает ошибку 404 not found), но метод, описанный в вопросе, на самом деле не использует соленый хэш.
по сути, этот метод просто использует нестандартный хэш: учитывая конкретный пароль, есть одно уникальное значение, которое будет храниться в базе данных. Это все, что нужно для работы атаки rainbow tables: я могу предварительно вычислить хэш-значение для словаря вероятных паролей и искать любой матч. Теперь мне придется предварительно вычислить таблицы rainbow специально для этой нестандартной хэш-функции.
при правильной реализации соленых хэшей, когда создается passord, случайная соль объединяется с паролем и хэшируется. Затем используется случайная соль и сохраняется хэш. Даже если я знаю пароль, я не могу предсказать, каким будет хэш, поскольку для каждого из многих возможных значений соли будет другой хэш. Теперь злоумышленнику нужно предварительно вычислить радугу таблица для каждого возможного значения соли: это требует гораздо больших усилий.