Изменение пароля ASP.NET - проблемы безопасности?
Я видел различные вопросы расценить эту проблему, но существует несколько вопросов, которые не задали. Если бы пользователь забывает их пароль, я хотел бы, чтобы они смогли сбросить его только со своим адресом электронной почты (т.е. нет никакого вопроса/ответа о безопасности). Пароль хранится как соленый хеш, таким образом, нет никакого возможного восстановления. Вместо этого я был бы точно так же, как пользователь для ввода нового пароля после подтверждения, что они запросили сброс.
Общепринятая методика это было упомянуто, только к:
1) Создайте случайный Гуид/Криптографически сильное случайное число
2) Отправьте уникальный URL, содержащий случайное число на адрес электронной почты пользователя
3) При подтверждении пользователя просят изменить пароль
Однако не, это открывается к a MITM нападение? При отправке временные пароли по Интернету на электронное письмо небезопасны, каково различие между выполнением этого и просто отправкой уникального URL, к которому может перейти взломщик? Я пропустил ключевой шаг где-нибудь, который сделает эту систему более безопасной (Или есть ли лучший способ изменить пароль)?
Спасибо
3 ответа
Если вы правильно построите свой хэш, щелчок URL придется поступить от IP-адреса, который запросил сброс. Это потребует MITM для подъема IP и / или фальсифицированных заголовков. Хотя это возможно, тем более уникальнее вы можете идентифицировать ташу рассматриваемой системы, тем сложнее он становится «окончить» хеш.
Также рекомендуется, чтобы Гидик был односторонним хэш определенным критерием. Также возможно зашифровать системные данные в запросе с использованием открытого ключа, который разблокирует закрытый ключ, чтобы при нажатии URL-адреса эти же публичные зашифрованные системы системы должны сопровождать хеш, а также единственной системой, которая может быть связана с этими ценностями, Частный ключ проводится на сервере. В основном прессование PSuedo-PKi к хэш.
Для смягчения риска человека в средней атаке я использую следующие меры:
- Запрос сброса может использоваться только один раз.
- Если запрос сброса не используется, он истекает через один час.
- Все запросы сброса постоянно регистрируются, в конечном итоге это было завершено или истекло.
Ваше средство аутентификации пользователя является общим секретом (пароль).
Если пользователь забудет, что секрет, вам нужен способ создания нового общего секрета. Независимо от того, каким образом вы идете об этом, у вас все еще есть проблема аутентификации пользователя, чтобы поделиться этим новым секретом.
Если единственное, что вы знаете о пользователе, который можно использовать для аутентификации им, является их адрес электронной почты, то вам понадобится какой-то способ подтвердить, что пользователь, запрашивающий сброс, контролирует этот адрес электронной почты.
И единственный путь до сих пор, чтобы сделать это, чтобы по электронной почте секрет этого адреса электронной почты и проверьте, его получают.
, который всегда будет открыт для достаточно подлый удар MITM.
Причина, по которой вы не отправляете временный пароль, состоит в том, чтобы избежать проблемы «пользователь не может быть обеспокоен изменением и поэтому сохраняет использование небезопасного временного пароля вместо их собственного безопасного».