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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

РЕДАКТИРОВАТЬ : Что касается вопроса в вашем редактировании - я бы предложил:

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

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

Answer 3

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

Принудительно сменить пароль при получении и ввести новый пароль.

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

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

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

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

См. Демо здесь .

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

Answer 7

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

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