Забыли пароль: какой лучший способ реализации функции забытого пароля?

Мне интересно, какой лучший способ для создания функции забытого пароля на веб-сайте. Я видел немало там, вот несколько или комбинация:

вопрос/ответ с парольной фразой (1 или более)
отправить электронное письмо с новым паролем
на экране введите новый пароль
подтверждение по электронной почте: необходимо щелкнуть ссылку, чтобы получить новый пароль
требующая ввода нового пароля

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

Я работаю с директором, что пароль не может быть восстановлен; необходимо ввести/сгенерировать новый пароль.

Изменить Мне нравится, что Кори сказал о том, что не отображается, если имя пользователя существует, но мне интересно, что отображать вместо этого. Я думаю, половина проблемы заключается в том, что пользователь забыл, какой адрес электронной почты они использовали, который показывает какое-то сообщение "не существует". Любые решения?

Ответ 1

Я лично отправлю электронное письмо со ссылкой на короткую страницу, которая позволяет им установить новый пароль. Сделайте имя страницы своего рода UID.
Если это не понравится вам, то отправьте им новый пароль и заставите их изменить его при первом доступе, также сделайте.

Вариант 1 намного проще.

Ответ 2

Несколько важных проблем безопасности:

Вопрос/ответ с парольной фразой фактически снижает безопасность, поскольку он обычно становится самым слабым звеном в этом процессе. Часто бывает легче угадать, кто-то отвечает, чем пароль, особенно если вопросы не выбраны тщательно.
Предполагая, что электронные письма работают как имя пользователя в вашей системе (что обычно рекомендуется по разным причинам), ответ на запрос пароля reset не должен указывать, была ли действительная учетная запись найдена. Он должен просто указать, что письмо с запросом пароля отправлено на указанный адрес. Зачем? Ответ, указывающий, что письмо существует/не существует, позволяет хакеру собирать список учетных записей пользователей, отправляя несколько запросов на пароли (обычно через прокси-сервер HTTP, например, пакет burp), и отмечая, обнаружено ли электронное письмо. Чтобы защитить себя от сбоев при входе в систему, вы должны убедиться, что никакие функции, связанные с login/auth, не дают никаких указаний о том, когда в форму логина/пароля reset была введена действительная электронная почта пользователя.

Для получения дополнительной информации ознакомьтесь с Справочник по хакерам веб-приложений. Это отличное чтение о создании безопасных моделей аутентификации.

EDIT. Что касается вопроса в вашем редактировании, я бы предложил:

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

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

Ответ 3

Отправьте электронное письмо с новым паролем.

НАЧАТЬ изменение пароля при поступлении и ввести новый пароль.

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

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

Также отправьте подтверждения изменениям пароля пользователям.

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

Ответ 4

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

Ответ 5

Я бы подумал (вариант gbrandt). Вариант 2 был бы отличным методом, если бы он сочетался с некоторой личной информацией, которую у вас уже есть для пользователя. i.e дата рождения.

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

Только те, кто его хорошо знает, могут раздражать его, сбросив его пароль! Он не может быть незнакомцем или ботом

После 5 или 7 неправильных адресов электронной почты и даты рождения, пользователь отправляется по электронной почте, что его пароль был запрошен как reset и не удалось из-за неправильных учетных данных. Затем сброс пароля для этой учетной записи приостанавливается на 24 часа или в любой желаемый период.

(если слишком много пользователей свяжутся с webadmin относительно этого письма, он узнает, что кто-то пытается злонамеренно получить информацию с вашего сайта/приложения)

Что вы, ребята, думаете?

Ответ 6

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

Другие варианты лучше, и предыдущие сообщения обрисовали детали.

Ответ 7

Я реализовал проект JAVA для этого варианта использования. Он находится на GitHub, с открытым исходным кодом. Он отлично отвечает на ваш вопрос... реализован на Java.

Что касается ссылки в письме - он создает ссылку, а также проверяет ее при использовании.

Есть объяснения для всего (и если что-то отсутствует - дайте мне знать...)

Посмотрите: https://github.com/OhadR/Authentication-Flows

Смотрите Демо здесь.

Это клиентское веб-приложение, использующее auth-потоки, с README со всеми пояснениями. он направляет вам реализацию: https://github.com/OhadR/oAuth2-sample/tree/master/authentication-flows