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

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

  • вопрос/ответ с парольной фразой (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