Забыли пароль: каков наилучший способ реализации функции забытого пароля?
Мне интересно, как лучше всего создать функцию забытого пароля на веб-сайте. Я видел немало там, вот несколько или комбинация:
- пароль / вопрос / ответ (1 или более)
- отправить письмо с новым паролем
- на экране введите новый пароль
- подтверждение по электронной почте: необходимо нажать на ссылку, чтобы получить новый пароль
- страница, требующая от пользователя ввода нового пароля
Какую комбинацию или дополнительные шаги вы бы добавили к функции забытого пароля? Мне интересно, как они запрашивают новый пароль и как они в итоге его получают.
Я работаю на принципале, что пароль не может быть восстановлен; новый пароль должен быть предоставлен / сгенерирован.
Редактировать Мне нравится то, что сказал Кори о не отображении, если имя пользователя существует, но мне интересно, что отображать вместо этого. Я думаю, что половина проблемы заключается в том, что пользователь забыл, какой адрес электронной почты он использовал, и какое-то сообщение "не существует" полезно. Какие-либо решения?
7 ответов
- Я лично отправил бы электронное письмо со ссылкой на кратковременную страницу, которая позволит им установить новый пароль. Сделайте имя страницы своего рода UID.
- Если это вас не устраивает, то отправка им нового пароля и принуждение к его изменению при первом доступе также подойдет.
Вариант 1 намного проще.
Несколько важных проблем безопасности:
- Парольная фраза вопрос / ответ на самом деле снижает безопасность, поскольку обычно становится самым слабым звеном в процессе. Зачастую легче угадать чей-то ответ, чем пароль, особенно если вопросы тщательно не выбраны.
- Предполагая, что электронные письма работают как имя пользователя в вашей системе (что обычно рекомендуется по разным причинам), ответ на запрос сброса пароля не должен указывать, была ли найдена действительная учетная запись. Следует просто указать, что электронное письмо с запросом пароля было отправлено на указанный адрес. Зачем? Ответ, указывающий, что электронная почта существует / не существует, позволяет хакеру собрать список учетных записей пользователей, отправив несколько запросов на пароль (обычно через HTTP-прокси, например, пакетный пакет), и отметив, найдена ли электронная почта. Для защиты от сбора входа в систему вы должны убедиться, что никакие функции, связанные с входом в систему / аутентификацией, не дают никаких указаний на то, когда в форму входа в систему / пароль был введен действительный адрес электронной почты пользователя.
Для получения дополнительной информации обратитесь к Руководству по хакерам веб-приложений. Это отличная статья о создании моделей безопасной аутентификации.
РЕДАКТИРОВАТЬ: Что касается вопроса в вашем редактировании - я бы предложил:
"На указанный вами адрес электронной почты было отправлено электронное письмо с запросом пароля. Если письмо не пришло в ближайшее время, проверьте папку со спамом. Если письмо не пришло, значит, аккаунт с указанным вами адресом не существует".
Здесь делается компромисс между простотой использования и безопасностью. Вы должны сбалансировать это на основе контекста - достаточно ли важна безопасность для вас и ваших пользователей, чтобы оправдать это неудобство?
Отправить письмо с новым паролем.
Принудительно смените пароль, когда он прибудет, и введите новый пароль.
Это гарантирует, что человек, который хотел пароль, будет единственным, кто получит доступ к учетной записи.
Если электронная почта будет прослушана, кто-то может войти в учетную запись (конечно), но реальная сторона обнаружит это немедленно (так как их пароль, который вы только что отправили, не работает).
Также отправьте подтверждение смены пароля пользователям.
Если кто-то получит новый пароль, а затем письмо с надписью "спасибо за изменение пароля", они будут весьма озадачены и, если они этого не сделают, поговорят с администратором.
Использование ссылки подтверждения электронной почты / сброса пароля обеспечит вам большую безопасность. Если вы посмотрите, как это делают большинство веб-сайтов, и люди довольно привыкли к этой проверке, поэтому я бы рекомендовал использовать этот тип аутентификации.
Я думаю, вариант 2 (gbrandt's) был бы отличным методом, если бы он сочетался с некоторой личной информацией, которая у вас уже есть для пользователя. т.е. дата рождения.
Когда пользователь запрашивает новый пароль (сброс) путем ввода своего адреса электронной почты, он также должен ввести правильную дату рождения (или что-то еще), прежде чем пароль будет сброшен, и новый пароль будет отправлен пользователю по электронной почте.
Только те, кто его хорошо знает, могут раздражать его, сбрасывая его пароль! Это не может быть незнакомец или бот
После 5 или 7 неправильных комбинаций адреса электронной почты и даты рождения пользователю по электронной почте отправляется запрос на сброс пароля из-за неправильных учетных данных. Тогда сброс пароля для этой учетной записи приостанавливается на 24 часа или на любой другой желаемый период.
(если слишком много пользователей обращаются к веб-администратору в связи с этим письмом, он узнает, что кто-то пытается злонамеренно получить информацию с вашего веб-сайта / приложения)
Что, вы парни, думаете?
Вариант 1. не очень хорошая идея, так как обычно его легко угадать другим. Таким образом, личная электронная почта Сары Пэйлин (Yahoo, я думаю) была взломана третьей стороной.
Другие варианты лучше, и предыдущие посты обрисовали в общих чертах детали.
Идея, о которой я думал, заключалась в том, чтобы подписать данные в ссылке, отправленной пользователю. Затем, когда пользователь щелкает ссылку и сервер принимает вызов, сервер также получает зашифрованную часть и может проверить, что данные не были затронуты.
Я реализовал проект JAVA для этого варианта использования. Это на GitHub, с открытым исходным кодом. Он отлично отвечает на ваш вопрос... реализован на Java.
Что касается ссылки в электронном письме - она генерирует ссылку, а также проверяет ее при использовании.
Есть объяснение всему (и если чего-то не хватает - дайте мне знать...)
Посмотрите: https://github.com/OhadR/Authentication-Flows
Посмотреть демо здесь.
Это клиентское веб-приложение, использующее потоки аутентификации, с README со всеми пояснениями. он направляет вам реализацию: https://github.com/OhadR/oAuth2-sample/tree/master/authentication-flows