Хеширование паролей с помощью ASP.NET MVC 3 - PullRequest
7 голосов
/ 18 июня 2011

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

Мой второй вопрос: какой метод хеширования лучше использовать?Я читал, что MD5 (который я всегда использовал) очень легко взломать.Я слышал, что bcrypt / sha512 довольно хороши.Какой из них следует использовать?Я знаю, что C # по умолчанию поставляется с хэшированием sha512.Из того, что я вижу, bcrypt не входит в библиотеку .NET, есть ли хорошие библиотеки для C # и bcrypt?

Ответы [ 6 ]

10 голосов
/ 20 сентября 2012

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

В .NET этот API-интерфейс сделает все, что вам нужно, он создаст большую криптослучайную соль, а также хеширование HMACSHA512 и растяжение ключа путем замены байтов перед каждым проходом шифрования AES:)

http://sourceforge.net/projects/pwdtknet/

1 голос
/ 18 июня 2011

Вот хорошая реализация bcrypt на C #:

http://bcrypt.codeplex.com/

1 голос
/ 18 июня 2011

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

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

Взгляните на http://msdn.microsoft.com/en-us/library/ff398049%28v=VS.98%29.aspx и http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx. Если вы используете систему членства .NET, вам не нужно выполнять низкоуровневое управление базами данных или паролями.Вы просто помещаете теги [Authorize] вокруг действий контроллера, которые должны быть авторизованы, и все готово.

1 голос
/ 18 июня 2011

SHA512 - хороший выбор для хэширования в .net, и если вы храните соль с паролем, это немного бессмысленно (но для «дешифрования» все равно потребуется больше времени), но вы можете хранить соль где-то ещеТаким образом, БД не достаточно:

  • храните соль где-то еще
  • всегда используйте одну и ту же соль и, например, жестко закодируйте ее в коде или сохраните в настройках приложения
  • генерация соли для каждого пользователя из некоторой другой информации, например, MD5 идентификатора пользователя
  • генерация соли для всех пользователей из некоторых системных настроек, таких как имя хоста или аналогичные

ОБНОВЛЕНИЕ:
Как уже говорил Майк, я ошибаюсь с "бессмысленным" утверждением выше.Даже когда соль известна, она сделает Радужный стол Атаки бесполезными (или намного более маловероятными), поэтому вы всегда должны использовать соль, даже если она хранится прямо рядом с хешем (например, Linux хранитпользовательские пароли в теневом файле в форме "$ id $ salt $ hashed")!

0 голосов
/ 09 июня 2015

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

0 голосов
/ 18 июня 2011

Я всегда использовал следующий подход для хранения паролей

public static string MD5Hash(string value)
{
    return Convert.ToBase64String(new MD5CryptoServiceProvider().ComputeHash(new UTF8Encoding().GetBytes(value)));
}

Никогда не возникало вопроса, можно ли восстановить такой хэш до исходного пароля.

...