Сброс пароля ASP.NET - проблемы безопасности?

Question

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

Обычный упомянутый метод заключается в следующем:

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

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

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

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

Спасибо

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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