Мне нужно сохранить хэш одного пароля в приложении .Net WinForms.
Какой самый безопасный способ сделать это?
В частности:
Я предполагаю, что алгоритм должен быть либо SHA512, либо HMACSHA512.
Солить свой хэш с безопасной случайной солью не менее 128 бит или дольше, чтобы избежать атаки радуги и использовать BCrypt, PBKDF2 или scrypt. PBKDF2 поставляется с утверждением NIST.
Проблема в том, что MD5 работает быстро. Так же и его современные конкуренты, например SHA1 и SHA256. Скорость - это дизайн цель современного безопасного хэша, потому что хеши - это строительный блок почти каждой криптосистеме, и обычно выполнение запроса по каждому пакету или для каждого сообщения.
Скорость - это именно то, чего вы не хотите в хэш-функции пароля.
Быстрые функции проверки пароля являются проблемой, потому что они могут быть атакованы с использованием грубой силы. Со всеми вышеперечисленными алгоритмами вы можете управлять "медлительностью"
Я могу порекомендовать 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);
Для реализации на стороне сервера с большим количеством паролей необходимо обязательно использовать настраиваемый итерационный подход, например, bcrypt. Эта известная статья по этой теме по-прежнему (в основном) актуальна:
http://www.securityfocus.com/blogs/262
Для одного пароля в автономном приложении, где место хранения, вероятно, уже защищено системой собственной аутентификации системы, я думаю, что это гораздо менее важно. Один сильный хеш, вероятно, достаточно хорош, и добавление соли достаточно просто, чтобы не было причин не делать этого.
RNGCryptoServiceProvider для генерации случайной соли, затем SHA512 пароль с солью, и, наконец, сохраните как хэш пароля, так и соответствующую соль, если вы хотите позже проверить, что какой-то текст равен сохраненному паролю.
Хеш и соль. Если вы только хеш, вы можете атаковать с помощью радужной атаки (обратный поиск), и соль делает это намного сложнее (случайная соль будет лучше). Для вашей кодировки вы, вероятно, захотите либо Base64, либо Hex закодировать полученный массив байтов, Если вы просто попытаетесь сохранить массив байтов как Unicode, вы можете запустить риск потери некоторых данных, потому что не все шаблоны являются допустимыми символами. Это также позволяет упростить сравнение хэшей (просто сравните base64 или шестнадцатеричную строку, если вы хотите проверить вместо сравнения массива байтов)
Увеличенное количество раундов не делает ничего, кроме замедления, будут атакующими. Но также значительно сложнее повторно использовать хеши в будущем, если вы потеряете или хотите воссоздать свой хэш-алгоритм. Вы можете проверить стандартный хэш пароля, например crypt в Unix-системах. Это позволяет вам изменить алгоритм хэширования и даже поддерживать управление версиями.
Но опять же, простая хэш + соль достаточно хороша для большинства приложений.
Строго смотря на более безопасное:
Salt, HMAC, or both?
Оба будут более безопасными. Поскольку ключ к HMAC можно считать солью, то выполнение обоих будет немного избыточным, но еще более безопасным, потому что потребуется больше усилий для взлома.
How much salt?
Каждый бит соли удваивает комбинации, которые нужно поддерживать в радужном столе, чтобы легко взломать пароль. Но поскольку есть только один пароль и только одна соль, больше не требуется. HMAC использует размер блока базового хэша для его размера ключа, 1024 бит для SHA512. Размер блока должен быть достаточно хорош для соли, но удвоение или утроение его сделают взломать пароль с помощью радужного стола намного сложнее.
How many iterations?
Чем лучше, тем лучше. Конечно, больше итераций означает, что потребуется больше времени, чтобы определить, был ли введен правильный пароль, но компьютеры быстрые, и пользователи не возражаете ждать несколько секунд, проверяя пароль. Выполнение большего количества итераций означало бы, что кто-то, взломавший пароль, должен будет сделать больше итераций.
What encoding? (The password is plain ASCII)
Можно также зашифровать (с AES) чрезмерно повторный, сверхсоленный, HMAC'ed, супер-безопасный пароль вместе со своей солью, чтобы сделать его сложнее. Создайте пароль для зашифрованного пароля хэша и ключа, будь то комбинация строк, которые должны появляться в исполняемом файле, такие как "RNGCryptoServiceProvider" или "System.Security.Cryptography". И при кодировании мы могли бы также преобразовать шестнадцатеричный или base64 или, еще лучше, базу-36 или другое менее ожидаемое преобразование.
Примечание: Это было написано в основном шутка, но должно содержать некоторую правду.
Я думаю, вы должны придерживаться открытых стандартов. Среди существующих хеш-схем "{ssha}", используемый OpenLDAP, очень безопасен и широко используется. Здесь вы можете найти описание,
http://www.openldap.org/faq/data/cache/347.html
Большинство библиотек LDAP реализуют эту схему.
Вы можете следовать опубликованному стандарту, например pkcs # 5. см. http://en.wikipedia.org/wiki/PKCS для краткого описания или http://tools.ietf.org/html/rfc2898 для RFC.
Вот API, который сделает все, что вам нужно:)