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

Specific Questions

Does using a integer unique user ID fail as an effective salt? (crypt() uses only 16 bits?)

If I simply run sha256() on a hash over and over until a second is used up does that defeat the brute-force attacks?

If I have to ask these questions should I be using bcrypt?

Discussion/Explanation:

Цель состоит в том, чтобы просто, если хешированные пароли моего пользователя были слиты, они:

would not be "easy" to crack, cracking one password would not expose other users that use the same password).

То, что я прочитал для # 1, - это то, что вычисление хеша должно быть дорогостоящим, например, требовать, скажем, секунды или две для вычисления и, возможно, потребовать бит или память (чтобы помешать аппаратному дешифрованию).

В bcrypt это встроено, и scrypt, если я правильно понимаю, более ориентирован на будущее и включает в себя требование минимального использования памяти.

Но является ли такой же эффективный подход, чтобы «съесть время» путем «перефразирования»? результат sha256 () столько раз, сколько нужно, чтобы использовать несколько секунд и затем сохранить окончательный счетчик циклов с помощью хэша для последующей проверки предоставленного пароля?

Для # 2 важно использовать уникальную соль для каждого пароля. Неясно, насколько случайной (или крупной) должна быть соль. Если цель состоит в том, чтобы избежать всех, кто использует & quot; mypassword & quot; как их пароль от того же хэша, разве недостаточно просто сделать это?

hash = sha256_hex( unique_user_id + user_supplied_password );

или даже это, хотя я не уверен, что он мне что-нибудь купит:

hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );

Единственное преимущество, которое я вижу от использования идентификатора пользователя, кроме того, что я знаю, что он уникален, - это избегание необходимости сохранять соль вместе с хешем. Не так много преимуществ. Есть ли реальная проблема с использованием идентификатора пользователя в качестве соли? Разве это не достигло # 2?

Я предполагаю, что если кто-то сможет украсть хешированные пароли моих пользователей, то я должен предположить, что они могут получить все, что захотят, включая исходный код, который генерирует хэш. Итак, есть ли польза от добавления дополнительной случайной строки (той же строки) к паролю перед хэшированием? То есть:

# app_wide_string = one-time generated, random 64 7-bit *character* string.
hash = sha256_hex( unique_user_id + app_wide_string + user_supplied_password );

Я видел, что предложено, но я не понимаю, что я получаю от этого по соли для каждого пользователя. Если бы кто-то хотел перехватить атаку, он бы знал, что & quot; app_wide_string & quot; и использовать это при запуске атаки по словарю, верно?

Есть ли веская причина использовать bcrypt вместо того, чтобы переворачивать мой собственный, как описано выше? Может быть, тот факт, что я задаю эти вопросы, является достаточной причиной?

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

Некоторые связанные ссылки:

использование sha256 в качестве хэширования и посола с идентификатором пользователя

SHA512 против Blowfish и Bcrypt

Какова оптимальная длина для соли пароля пользователя?