Хеширование против шифрования паролей - PullRequest
4 голосов
/ 09 февраля 2011

Я использую членство в ASP.NET для сайта, который будет обслуживать в первую очередь искушенных пользователей.Я понимаю разницу между хешированными и зашифрованными паролями, и я пытаюсь выбрать между ними.

После того, как мой последний клиент горько пожаловался на то, что хешированные пароли являются полной PITA, я начал отдавать предпочтение зашифрованным паролям.Но кто-то предположил, что это просто недостаточно безопасно.

Итак, мой вопрос: что именно представляет собой риск шифрования паролей?Любой человек, способный украсть пароли, расшифровав их из базы данных, наверняка сможет сбросить их, если они были хешированы, не так ли?У меня проблемы с поиском, где кто-то может вызвать проблемы с зашифрованными паролями, но не может с хешированными.Также важно сделать его удобным для пользователей.

Ответы [ 4 ]

15 голосов
/ 09 февраля 2011

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

  • С зашифрованным паролем, украденным / расшифрованным паролемможет быть опробован на других учетных записях пользователей (например, украденный банковский пароль может привести к доступу к их электронной почте).
  • При хешированном пароле восстановление невозможно.Кража хэшей паролей никогда не должна легко приводить к пригодным для использования паролям

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

6 голосов
/ 09 февраля 2011

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

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

Редактировать
Поскольку вы отметили вопрос ASP.Net, я бы порекомендовал использовать библиотеку BCrypt.Net для генерации ваших хэшей

1 голос
/ 09 февраля 2011

Как говорили другие пользователи, зашифрованные пароли могут быть расшифрованы и не являются хорошей идеей.

Если вы используете стандартную технику хеширования, пользователь, имеющий доступ к вашей базе данных, может поместить в стандарт md5 для "пароль "например.Вы можете решить эту проблему с помощью соленого хэша, который принимает входную строку и значение солевой строки, чтобы создать уникальный хеш, который не может быть легко скопирован.Храните его в безопасном месте и используйте sha1 ($ salt. $ Input).Теперь у вас есть соленый хеш.

1 голос
/ 09 февраля 2011

Риск заключается в том, что зашифрованные пароли можно расшифровать, чтобы получить простой текстовый пароль.

Обычно хеши не могут быть сторнированы.

Сторнирование хэша MD5

Довольно распространенное явление - люди, использующие одно и то же имя пользователя и пароль на всех своих интернет-сайтах.

Все, что требуется, - это один пароль для дешифрования, и все сайты пользователей находятся в опасности.

При использовании хэша взломщик никогда не получает простой текстовый пароль.

...