Какой алгоритм хеширования рекомендуется использовать для сохраненных паролей?

Question

Учитывая известные слабости MD5 и недавние (май 2009 г.) слабости, обсуждаемые в SHA1, как новым программам следует посолить и хэшировать свои пароли?

Я видел предложенные SHA-256 и SHA-512.

Программирование преимущественно на Ruby on Rails и использование PostgreSQL - но другие языки и среды также могут рассчитывать хэши паролей.

Answer 1

SHA-256 и SHA-512 безопасны в обозримом будущем. Они принадлежат к семейству SHA-2, против которого до сих пор не было выявлено никаких нападений. На этой странице википедии говорится, что поставщики Unix и Linux только сейчас переходят на SHA-2 для безопасного хэширования паролей. Семейство SHA-3 с еще более сильными алгоритмами разрабатывается, но не будет готово по крайней мере до 2012 года.

П.С .: Если вы не скрываете имена секретных агентов от правительств, вы также будете в безопасности с SHA-1, но если нет проблем с внедрением SHA-2, просто используйте его вместо этого.

Answer 2

Используйте медленную функцию, такую ​​как bcrypt. Здесь - сообщение от ребят из Phusion.

Answer 3

В качестве результата uid / pwd вы должны использовать функцию получения ключа на основе пароля; наиболее известным из них является PBKDF2 http://en.wikipedia.org/wiki/PBKDF2, также определенный как RFC 2898 http://tools.ietf.org/html/rfc2898. PKBDF2 принимает ваши секретные данные, а также солт и число итераций. Это стандартный способ решения вашей проблемы.

Если вы программируете в .NET, используйте Rfc2898DeriveBytes http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

Answer 4

Вы должны использовать хеш-имя пользователя, пароль и соль вместе, например:

hash(length(username)+"_veryuniquesalt4rtLMAO"+username+password)

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

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

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

Независимо от того, что вы выберете, немного медленное хеширование гораздо лучше, чем ничего, используйте 1 миллисекунду вместо 1 микросекунды иваша защита в 1000 раз сильнее.

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

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