Защита пароля перед сохранением в базе данных - PullRequest
Новая
       22

Защита пароля перед сохранением в базе данных

1 голос
/ 03 октября 2011

Я использую пример кода хеширования паролей ASP.NET, приведенный в этой статье. Он использует 32-байтовый экземпляр RNGCryptoServiceProvider для Salt и экземпляр SHA256Managed для хеширования.

  1. Видите ли вы какие-либо проблемы с подходом, описанным здесь, для использования в производственной среде.
  2. Я не понимаю, зачем нужен метод BytesToHex, а также почему к нему добавляется «x2». Есть идеи?
  3. Если я хочу сохранить этот хешированный пароль (восстановленный методом HashPassword) в базе данных SQL Server, какой тип данных следует использовать. CHAR (128), VARCHAR (128) или что-то еще с плюсами и минусами каждого подхода.

ТИА

Ответы [ 2 ]

3 голосов
/ 03 октября 2011

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

  2. Шифрование .NET обрабатывает байты,и большинство других систем выдают шестнадцатеричные представления этих байтов - посмотрите на примеры PHP.Задача метода BytesToHex - выполнить это преобразование.Использование «x2» в методе ToString указывает байтам, какой формат использовать - в данном случае Hexidecimal.Более подробное объяснение см. в документации .

  3. Сначала см. № 1.Лично, если бы я катал свой собственный, я бы использовал VARBINARY или BINARY и не делал преобразование текста - это пустой шаг, так как .NET все равно хочет рассматривать его как байт [].Если вам нужен текст, и вы были уверены, что никогда не меняли свой метод кодирования или хэширования, то я думаю, что CHAR (LENGTH_OF_HASH) будет наиболее эффективным вариантом хранения.

1 голос
/ 03 октября 2011

Видите ли вы какие-либо проблемы с подходом, описанным здесь, для использования в производственной среде.

Хорошо, давайте сначала поговорим о хешировании.Во-первых, вы должны знать, что простой Hash (Salt + Password) может быть взломан достаточно легко, когда люди используют общие пароли.Таким образом, один только соленый хеш обычно не выигрывает у вас много времени, прежде чем они взломают большой процент паролей вашего пользователя.

Сценарий: допустим, вам потребуется 24 часа, чтобы заметить, что было сделано нарушение.Многие учетные записи уже будут скомпрометированы в этом коротком окне.Вы сбросили все пароли учетных записей пользователей, теперь пользователи в безопасности, верно?Таким образом, вы отправляете электронные письма всем своим пользователям, информируя их о нарушении и советуя им сбросить свой пароль.Проблема в том, что эти глупые пользователи уже давно используют этот пароль в Интернете, один и тот же пароль для своего банка, электронной почты и т. Д. Так что даже после того, как вы перестанете получать доступ к вашему сайту с украденными паролями, у пользователя могут появиться другие учетные записи, которые он долженсброс.Допустим, им требуется еще один день, чтобы получить электронное письмо и сбросить свои пароли.Как вы покупаете больше времени для пользователя?

Ответ PBKDF2 .Это увеличивает сложность хэша, поэтому каждый тест каждого пароля занимает тысячи раз дольше, чем простой соленый хеш.Для этого в .NET используется класс Rfc2898DeriveBytes .См. Рабочий пример, прочитав: « Еще один пример того, как хранить хэш с соленым паролем ».

Я не понимаю, зачем нужен метод BytesToHex, а также почему"x2" добавлен туда.Любые идеи?

Нет причин, о которых я могу думать.

Если я хочу сохранить этот хешированный пароль (повторно обработанный методом HashPassword) в базе данных SQL Server, какой тип данныхдолжен быть использован.CHAR (128), VARCHAR (128) или что-то еще с плюсами и минусами каждого подхода.

Лучше всего работают необработанные байты, Base64 также стоит рассмотреть, хотите ли вы сохранить его как текст.

...