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

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

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

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

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

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


authentication passwords change-password forgot-password
person Darryl Hein    schedule 07.02.2009    source источник

Ответы (7)


arrow_upward
48
arrow_downward

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

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

person Gregor Brandt    schedule 07.02.2009
comment
Вариант 1 также имеет то преимущество, что он невосприимчив к DoS-атакам на пользователя. Например, кто-то постоянно щелкает ссылку для сброса пароля в варианте 2, поэтому пользователь фактически заблокирован для своей учетной записи. Вы можете защититься от этого, но зачем беспокоиться? Вариант 1 - это то, что вам нужно ... - person William Brendel; 07.02.2009
comment
+1 за редкий звуковой экземпляр, простой совет безопасности. Молодец. - person Jens Roland; 11.02.2011
comment
Есть ли причина, по которой пользователь не должен входить в систему после установки нового пароля? - person Tommy; 28.07.2011
comment
Я поддерживаю оба варианта, потому что 1-й вариант применим для веб-приложений, а второй вариант лучше всего подходит для мобильных приложений. - person JustCause; 03.02.2017

arrow_upward
25
arrow_downward

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

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

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

РЕДАКТИРОВАТЬ. Что касается вопроса в вашей редакции, я бы посоветовал:

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

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

person Cory House    schedule 07.02.2009
comment
разве вы не смогли бы определить, использовалось ли уже электронное письмо при регистрации? - person corymathews; 01.03.2011
comment
Да, хотя тот же подход можно использовать для уведомления существующих пользователей. Применяются те же предостережения в отношении простоты использования. - person Cory House; 05.03.2011

arrow_upward
8
arrow_downward

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

ПРИНУДИТЕЛЬНО изменить пароль, когда они поступят, и введите новый пароль.

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

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

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

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

person Will Hartung    schedule 07.02.2009
comment
ИМО плохая идея. Сниффер может нанести серьезный ущерб, прежде чем реальная сторона сможет связаться со службой поддержки клиентов. - person user1069528; 26.09.2016

arrow_upward
2
arrow_downward

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

person Brock Woolf    schedule 07.02.2009

arrow_upward
1
arrow_downward

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

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

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

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

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

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

person Auero    schedule 31.08.2010

arrow_upward
0
arrow_downward

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

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

person Jayden    schedule 07.02.2009
comment
Как легко угадать длинные случайно сгенерированные строки? - person slikts; 01.09.2010
comment
Моя ссылка на «Вариант 1» больше не понятна с другими сообщениями - это относится к первому варианту, представленному OP. Это относится к предложению использовать «секретный вопрос», на который при правильном ответе можно было бы задать вопрос, например, «в какой старшей школе вы ходили?». Извините за то, что это стало неясным. - person Jayden; 14.10.2010

arrow_upward
-1
arrow_downward

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

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

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

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

Взгляните: https://github.com/OhadR/Authentication-Flows

См. демонстрацию здесь.

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

person OhadR    schedule 19.01.2014
comment
Я бегло просмотрел исходный код, но не понял кода, который действительно работает. Итак, я задумался о sha-256 в конфигурации, означает ли это, что пароли хешируются с помощью одного вычисления хеша или это часть итерированного PBKDF2? Действительно ли соль получена из имени пользователя, а не из случайного источника операционной системы? Как хранится код забытого пароля, хранится ли он только как хэш? - person martinstoeckli; 28.04.2014
comment
пароли зашифрованы с использованием хранилища ключей + соли (имя пользователя). если пользователь забыл свой пароль, он не получит его, но вместо этого получит электронное письмо на свой почтовый ящик, поэтому мы убедимся, что ОН ЕДИНЫЙ (его личность). в письме есть зашифрованная ссылка, которая ведет его на страницу установки нового пароля. Вы можете попробовать это в демо (ссылка на демо находится выше) - person OhadR; 28.04.2014
comment
Мне кажется, что рабочий процесс хорош, и я подумал, как вычисляется хэш, или вы не используете хеш для хранения паролей в этом хранилище ключей? Для обеспечения безопасности это должен быть медленный адаптируемый алгоритм хеширования, такой как BCrypt или PBKDF2. Тогда соль в идеале должна быть действительно случайной, а не производной от других параметров. Когда я отправил форму забытого пароля, фреймворк отправил электронное письмо с токеном, и это хорошо, этот токен не должен храниться в базе данных, должен быть сохранен только его хеш. - person martinstoeckli; 28.04.2014
comment
на самом деле Spring выполняет кодировку - и они используют SHA256. в моем коде я использую тот же алгоритм для адаптации. плюс, чтобы быть защищенным - ссылка не хранится в БД. ссылка, отправляемая пользователю, зашифрована асимметричным ключом. имеет смысл? - person OhadR; 28.04.2014
comment
-1 объясните, что вы сделали, вместо того, чтобы указывать на внешний источник. - person Sanne; 10.06.2014
comment
@Sanne: если я напишу объяснение, вы проголосуете за? :-) - person OhadR; 18.06.2014
comment
@OhadR: Если это актуально и лучше, чем другой ответ, да, но, на мой взгляд, подобные ответы следует удалить. Практически ни у кого нет времени пойти к вашему источнику и все посмотреть. Этот сайт предназначен для того, чтобы оставаться в теме;) Это очень раздражающие ответы, как и ваш. Вставьте сюда часть вашего кода. - person Sanne; 24.06.2014
comment
@Sanne - я понимаю вашу точку зрения; Я согласен с принятым ответом; Я разместил это, потому что разработчики вынуждены реализовать это, потому что они не могут легко найти открытый исходный код, который делает это. Я подумал, что это подходящее место, чтобы сообщить этим разработчикам о моем бесплатном открытом исходном коде, который может им помочь - в этом вся суть SO ... - person OhadR; 24.06.2014
comment
@OhadR: Да, я понимаю. Но весь вопрос даже не касается определенного языка. Это действительно неуместно в моих глазах. Поэтому я разозлился, прочитав ваш ответ, достаточно, чтобы написать это сообщение, а теперь пишу свой третий ответ. Если вы действительно хотите продвигать свой собственный код, по крайней мере, дайте ответ или краткое содержание вопроса, а затем укажите ссылку. вместо того, чтобы просто сказать посмотри сюда ... Это не рекламный сайт. - person Sanne; 24.06.2014