Безопасное хеширование паролей

Question

Мне нужно хранить хэш одного пароля в приложении .Net WinForms.

Какой самый безопасный способ сделать это?

В частности:

• Соль, HMAC или оба?
• Сколько соли?
• Сколько итераций?
• Какая кодировка? (Пароль простой ASCII)

Я предполагаю, что алгоритм должен быть либо SHA512, либо HMACSHA512.

Answer 1

Посолите ваш хэш безопасной случайной солью не менее 128 бит или более, чтобы избежать атаки радуги, и используйте BCrypt , PBKDF2 или scrypt . PBKDF2 поставляется с утверждением NIST .

Цитировать: Archive.org: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Проблема в том, что MD5 работает быстро. Как и его современные конкуренты, такие как SHA1 и SHA256. Скорость это дизайн цель современного безопасного хэша, потому что хеши являются строительным блоком почти каждая криптосистема, и обычно получают выполняется по требованию для пакета или за сообщение.

Скорость - это именно то, что вам не нужно в хэш-функции пароля.

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

Answer 2

Я могу порекомендовать BCrypt.net . Очень прост в использовании, и вы можете настроить время, необходимое для хэширования, а это здорово!

// Pass a logRounds parameter to GenerateSalt to explicitly specify the
// amount of resources required to check the password. The work factor
// increases exponentially, so each increment is twice as much work. If
// omitted, a default of 10 is used.
string hashed = BCrypt.HashPassword(password, BCrypt.GenerateSalt(12));

// Check the password.
bool matches = BCrypt.CheckPassword(candidate, hashed);

Answer 3

Для реализации на стороне сервера с большим количеством паролей вам определенно следует использовать настраиваемый итеративный подход, такой как bcrypt. Эта известная статья на эту тему по-прежнему (в основном) актуальна:

http://www.securityfocus.com/blogs/262

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

Answer 4

Вот API, который будет делать все, что вам нужно / нужно:)

https://sourceforge.net/projects/pwdtknet

Answer 5

Вы можете следовать опубликованному стандарту, например, pkcs # 5. см. http://en.wikipedia.org/wiki/PKCS для краткого описания или http://tools.ietf.org/html/rfc2898 для RFC.

Answer 6

Я думаю, что вы должны придерживаться открытых стандартов. Среди существующих схем хеширования "{ssha}", используемый OpenLDAP, очень безопасен и широко используется. Вы можете найти описание здесь,

http://www.openldap.org/faq/data/cache/347.html

Большинство библиотек LDAP реализуют эту схему.

Answer 7

Строго глядя на более безопасный:

Salt, HMAC, or both?

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

How much salt?

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

How many iterations?

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

What encoding? (The password is plain ASCII)

Можно также зашифровать (с помощью AES) сверх-итеративный, сверхзащищенный, сверхзащищенный пароль HMAC вместе с его солью только для того, чтобы сделать его сложнее. Создайте пароль для хэша и ключа зашифрованного пароля, представляйте собой комбинацию строк, которые должны появляться в исполняемом файле, например «RNGCryptoServiceProvider» или «System.Security.Cryptography». И при кодировании мы могли бы также преобразовать его в шестнадцатеричное или base64, или, что еще лучше, в base-36 или в другое, менее ожидаемое преобразование.

Примечание: Это было написано в основном в шутку, но все же должно содержать некоторую правду.

Answer 8

Хэш и Соль. Если вы используете только хэш, вы можете быть атакованы радужной атакой (обратный поиск), и соль делает это намного более сложным (лучше всего использовать случайную соль). Для кодирования вы, вероятно, захотите либо Base64, либо Hex-кодирование полученного байтового массива , Если вы просто попытаетесь сохранить байтовый массив как Unicode, вы рискуете потерять некоторые данные, поскольку не все шаблоны являются допустимыми символами. Это также позволяет упростить сравнение хэшей (просто сравните base64 или шестнадцатеричную строку, когда вы хотите проверить вместо сравнения байтового массива)

Увеличенное количество раундов не намного превышает замедление атаки атакующих. Но это также делает гораздо более сложным повторное использование хэшей в будущем, если вы потеряете или вам потребуется пересоздать ваш алгоритм хэширования. Вы можете проверить стандартный хэш пароля, такой как crypt в системах Unix. Это позволяет вам изменить алгоритм хеширования и даже может поддерживать управление версиями.

Но опять же, простой хеш + соль достаточно хорош для большинства приложений.

Answer 9

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