Как долго должен быть мой пароль, и достаточно ли хорош SHA-256? - PullRequest
11 голосов
/ 07 июля 2010

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

Вот мой план: у каждого пользователя своя уникальная соль из 12 случайных символов (/ ¤ и т. Д.), Хранящиеся в таблице пользователей.Соль хэшируется (используя SHA-256) вместе с паролем при регистрации, и повторно хэшируется при входе в систему.

Как это звучит для вас?Что я могу улучшить?Должен ли я пойти на SHA-512 и более длинную соль, или этого достаточно?

Ответы [ 6 ]

17 голосов
/ 07 июля 2010

Ваше предложение 12 байтов должно быть достаточной длины для соли. Для этого потребуется атака по словарю для подготовки 2 96 баз данных хешированных паролей. Когда-нибудь это может быть тривиальной операцией для взломщика, но мы все еще далеки от этого.

NIST рекомендует SHA256 как имеющую достаточную силу хеширования для паролей, по крайней мере, на данный момент.

Если вы хотите изучить еще более надежные методы защиты паролем, обратите внимание на такие методы усиления ключей, как PBKDF2 или адаптивное хеширование с Bcrypt . Но они не имеют прямой поддержки в SQL. Вам нужно будет выполнить хеширование кода приложения, а затем опубликовать дайджест хеша в вашей базе данных.

Может показаться, что безопасность игрового сайта избыточна, но это хорошая практика. Потому что многие пользователи (нежелательно) используют тот же пароль для своего игрового логина, что и для своего банковского логина! Вы не хотите нести ответственность за нарушение аутентификации, которое косвенно ведет к крупным потерям.

4 голосов
/ 07 июля 2010

Обновление:

Не используйте хеширование или HMAC.Используйте bcrypt или scrypt.См. http://codahale.com/how-to-safely-store-a-password/

Оригинал:

Не просто хэш.Используйте HMAC.(И избегайте собственного хеширования или шифрования, если библиотека доступна, так как библиотеки получают пользу от экспертного ввода.)

Ссылки:

  1. http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/
  2. http://us2.php.net/manual/en/function.hash-hmac.php
3 голосов
/ 07 июля 2010

Это, вероятно, достаточно для вашего варианта использования.

Однако, это может быть улучшено с помощью:

  1. Увеличение размера соли

  2. Соль не должна быть ограничена небольшим подмножеством символов

  3. Повторять хеширование, скажем, 1000 раз (усиление ключа)

Взгляните на phpass .

1 голос
/ 25 марта 2011

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

Дополнительная информация и исходный код: Как правильно хешировать пароль

Не стесняйтесь делиться этой ссылкой, когда у кого-то возникает вопрос о хешировании пароля. Это мой первый пост на stackoverflow, извините, если я не делаю это правильно

0 голосов
/ 07 июля 2010

Если вы действительно обеспокоены, я бы посмотрел на использование функции хеширования вихревого потока вместо одного из вариантов SHA. Whirlpool оказался невероятно сильным методом хеширования, и у него нет истории столкновений или каких-либо других слабостей (по крайней мере, я знаю о них).

Вы можете использовать гидромассаж, используя функцию PHP hash . (Однако обратите внимание, что для hash () требуется PHP 5.1.2 или выше.)

0 голосов
/ 07 июля 2010

Ваш текущий подход достаточно.

...