Как долго должен быть мой пароль соли, и SHA-256 достаточно хорош?

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

Обновление:

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

Оригинал:

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

Литература:

Ответ 3

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

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

  • Увеличить размер соли

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

  • Итерируйте хеширование, скажем 1000 раз (усиление ключа)

Посмотрите phpass.

Ответ 4

Я заметил много путаницы в том, как правильно обрабатывать хэширование паролей, особенно в stackoverflow. И я видел некоторые ДЕЙСТВИТЕЛЬНО РЕАЛЬНЫЕ рекомендации. Поэтому я написал страницу, которая должна очистить все. Там немного больше, чем с помощью простого хэша.

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

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

Ответ 5

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

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

Ответ 6

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