Сброс ASP.NET проблемы с паролем?

Я видел различные вопросы, касающиеся этой проблемы, но есть несколько вопросов, которые не были заданы. Если пользователь забывает свой пароль, я хотел бы, чтобы они могли сбросить его только со своим адресом электронной почты (т. е. нет никакого секретного вопроса/ответа). Пароль хранится как соленый хэш, поэтому восстановление невозможно. Вместо этого я просто хотел бы, чтобы пользователь ввел новый пароль после подтверждения того, что они запросили сброс.

общий способ это было упомянуто просто:

1) Создайте случайное Guid / криптографически сильное случайное число

2) отправить уникальный URL, содержащий случайное число на электронную почту пользователя адрес

3) после подтверждения пользователю предлагается изменить пароль

однако, разве это не открыто для MITM атаки? Если отправка временных паролей через интернет на электронную почту небезопасна, в чем разница между этим и просто отправка уникального URL-адреса, на который злоумышленник может перейти? Я пропустил ключевой шаг, который сделает эту систему более безопасной (или есть лучший способ сброса пароля)?

спасибо

8
asp.net asp.net-membership forgot-password password-recovery security

3 ответов

Если вы правильно построите свой хэш, URL-адрес должен будет прийти с IP-адреса, который запросил сброс. Это потребовало бы, чтобы MITM подделал IP и / или фальсифицировал заголовки. Хотя это возможно, чем более уникальным вы можете определить хэш для рассматриваемой системы, тем труднее становится "завершить" хэш.

также рекомендуется, чтобы guid был односторонним хэшем определенных критериев. Также возможно шифровать системные данные в запросе использование открытого ключа, который разблокирует закрытый ключ, чтобы при нажатии url-адреса эти же открытые зашифрованные системные данные должны сопровождать хэш, и единственной системой, которая может расшифровать эти значения, будет закрытый ключ, хранящийся на сервере. В основном приложение psuedo-PKI к хэшу.

9

ваши средства аутентификации пользователя-это общий секрет (пароль).

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

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

и единственный способ сделать это-отправить Секрет на этот адрес электронной почты и проверить, получили ли они его.

который всегда будет открыт для достаточно подлой атаки MitM.

причина, по которой вы не отправляете временный пароль, заключается в том, чтобы избежать проблемы "пользователь не может беспокоиться об изменении и поэтому продолжает использовать небезопасный временный пароль вместо своего собственного безопасного."

7

чтобы уменьшить риск человека в середине атаки, я использую следующие меры:

  • запрос сброса можно использовать только один раз.
  • Если запрос на сброс не используется, он истекает через один час.
  • все запросы сброса постоянно регистрируются, был ли он в конечном итоге завершен или истек.
1