Хеширование безопасного пароля

I can recommend BCrypt.net. Very easy to use and you can tune how long it will take to do the hashing, which is awesome!

// 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);

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

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

Salt, HMAC или оба?

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

Сколько соли?

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

Сколько итераций?

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

Какая кодировка? (Пароль - простой ASCII)

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

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

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

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

You could follow a published standard, like pkcs#5. see http://en.wikipedia.org/wiki/PKCS for a short description, or http://tools.ietf.org/html/rfc2898 for the RFC.

For a server-side implementation with a large number of passwords, you should definitely use a tunable iterated approach like bcrypt. This well-known article on the topic is still (mostly) relevant:

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

For a single password in a stand-alone application, where the storage location is probably already secured by the system's own authentication system, I think it's much less important. A single strong hash is likely good enough, and adding salt is easy enough that there's no reason not to do so.

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

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

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