Все зависит от вашего сайта и уровня безопасности, которого вы пытаетесь достичь, но основной процесс для веб-приложения выглядит примерно так:
Пользователь переходит на страница «забыл свой пароль» и вводит их имя пользователя или адрес электронной почты (в зависимости от того, что является уникальным), чтобы запросить сброс пароля.
При желании на этом этапе вы можете подтвердить запрос, запросив дополнительную информацию, такую как ответ на заранее определенный секретный вопрос или дата их рождения и т. д. На этом дополнительном уровне пользователи не получают электронные письма, которые они не запрашивали.
Найдите учетную запись пользователя. Сохраните временный пароль (обычно GUID) и отметку времени напротив записи учетной записи. Отправьте пользователю электронное письмо с временным паролем.
Пользователь либо нажимает ссылку, содержащую временный пароль, либо имя пользователя ' s в электронном письме или переходит на страницу «забыл пароль» и копирует и вставляет временный пароль и их идентификатор. Пользователь вводит свой новый пароль и подтверждает его.
Найдите запись пользователя, и если текущее время находится в пределах указанного временного лимита (например, 1 час) отметки времени, сохраненной на шаге 2, то хешируйте и сохраните новый пароль. (Очевидно, только если совпадают временные пароли!). Удалите временный GUID и временную метку.
Принцип здесь заключается в том, что пользователю по электронной почте высылается временный пароль, который позволяет им изменить свой пароль. Первоначально сохраненный пароль (он должен быть хеширован!) Никогда не изменяется на временный пароль, если пользователь его помнит.
Исходный пароль никогда не будет отображаться пользователю, поскольку он должен быть хеширован и неизвестен.
Примечание : этот процесс полностью зависит от безопасности учетной записи электронной почты пользователя. Так что это зависит от уровня безопасности, которого вы хотите достичь. Обычно этого достаточно для большинства сайтов / приложений.
Когда вы отправляете любую информацию по электронной почте, она выиграла Ничего страшного. Есть слишком много способов получить это. Для опытного хакера, стремящегося украсть вашу информацию, это будет детская игра.
Воздержитесь от отправки любой личной информации, такой как пароли и сведения о доходах, по электронной почте, так как это может стать ОЧЕНЬ ЗАСТУПАЮЩИМ для вас и вашей организации, если такая информация будет утечкой или украдена. Серьезно подумайте о безопасности. Достаточно одного инцидента, чтобы все кирпичи упали.
Что касается восстановления пароля, внимательно прочтите Рекомендации по восстановлению пароля .
Суть в том, что приложение следование передовой практике должно позволить пользователь может сбросить свой пароль. Вопросы личной безопасности следует используемый. Заявление не следует отправлять электронная почта, отображение паролей и установка каких-либо временные пароли.
РЕДАКТИРОВАТЬ: Обновленная ссылка
Как уже говорилось, это зависит от требуемого уровня безопасности, однако, если вам нужен более высокий уровень, я видел некоторые новые решения, в том числе:
Отображение половины временного пароля после подтверждения личности пользователя (безопасность вопрос, адрес электронной почты и т. д.), затем вторая половина отправляется на адрес электронной почты. Если учетная запись электронной почты была скомпрометирована, маловероятно, что этому же человеку также удалось провести атаку типа «злоумышленник в середине». (См. На сайте UK Goverment Gateway)
Подтверждение личности по электронной почте и на другом носителе - например, код, отправленный с помощью текстового сообщения на зарегистрированный мобильный телефон. (См. На eBay / PayPal)
Поскольку где-то посередине между этими двумя крайностями, реализация вопросов безопасности может оказаться подходящим вариантом, как упомянул DaveG.
Если вы указали адрес электронной почты при регистрации. Кнопка «забыть пароль» отправляет электронное письмо на этот адрес электронной почты. Это гарантирует, что информация будет отправлена на доверенный адрес электронной почты.
(Если база данных не взломана, но тогда нет ничего безопасного).
Я бы использовал уникальные адреса электронной почты для всех учетных записей.
Затем нужно просто отправить ссылку на временную страницу, которая позволяет человеку изменить свой пароль. (подождите 24 часа или меньше)
Учетная запись электронной почты пользователя является самым слабым звеном в этом сценарии.
Обновление: улучшено в мае 2013 г.
password_change_requests
со столбцами ID
, Time
и UserID
. Когда новый пользователь нажимает кнопку, в таблице создается запись. Столбец Время
содержит время, когда пользователь нажал кнопку «Забыли пароль». ID
- это строка. Создается длинная случайная строка (скажем, GUID), а затем хешируется как пароль (что само по себе является отдельной темой). Затем этот хэш используется в качестве «идентификатора» в таблице. http://www.mysite.com/forgotpassword.jsp?ID=01234567890ABCDEF
. Забытый пароль. jsp-страница должна иметь возможность получать параметр ID. Извините, я не знаю Java, поэтому не могу сказать более конкретно. ID
из URL-адреса, снова хеширует его и сверяет с таблицей. Если такая запись существует и ее возраст составляет не более 24 часов, пользователю предлагается ввести новый пароль . Никогда не отправляйте пароль пользователю по электронной почте. Даже если он создается автоматически. Лучший подход (рекомендуется и используется SANS и другими):
Если он не щелкнет ссылку в течение 24 часов или около того, отключите ссылку (чтобы она больше не меняла пароль).
Никогда не меняйте пароль без согласия пользователя. Это означает, что не следует отправлять новый пароль по электронной почте только потому, что кто-то щелкнул ссылку на забытый пароль и выяснил имя учетной записи.