Сброс настроек ASP.NET пароль - проблемы с безопасностью?

Question

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

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

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

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

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

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

Спасибо

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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