Лучший способ реализации "забытого пароля"?

Я ищу лучший способ реализовать функцию "забытый пароль".

Я выхожу с двумя идеями:

  • Когда пользователь нажимает на забыли пароль, пользователь должен указать имя пользователя, адрес электронной почты и, возможно, дату рождения или фамилию. Затем почта с временным паролем будет отправлена ​​на учетную запись электронной почты пользователя. Пользователь использует временный пароль для входа и сбрасывает свой пароль.

  • Аналогично, но письмо будет содержать ссылку, позволяющую пользователю reset его пароль.

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

ОТВЕТЫ

Ответ 1

Обновление: пересмотрено в мае 2013 года для лучшего подхода

  • Пользователь вводит свое имя пользователя и хиты "забыли пароль". Я также рекомендую ввести адрес электронной почты вместо имени пользователя, потому что иногда также забывают имена пользователей.
  • Система имеет таблицу password_change_requests со столбцами ID, Time и UserID. Когда новый пользователь нажимает кнопку, в таблице создается запись. Столбец Time содержит время, когда пользователь нажал кнопку "Забыли пароль". ID - строка. Создается длинная случайная строка (например, GUID), а затем хешируется как пароль (что само по себе является отдельной темой). Этот хэш затем используется как "ID" в таблице.
  • Система отправляет электронное письмо пользователю, содержащему ссылку. Ссылка также содержит исходную строку идентификатора (перед хэшированием). Ссылка будет примерно такой: http://www.mysite.com/forgotpassword.jsp?ID=01234567890ABCDEF. Страница forgetpassword.jsp должна иметь возможность получить параметр ID. Извините, я не знаю Java, поэтому я не могу быть более конкретным.
  • Когда пользователь нажимает на ссылку в письме, он перемещается на вашу страницу. Страница извлекает ID из URL, снова хеширует и проверяет таблицу. Если такая запись есть и не больше, чем, скажем, 24 часа, пользователю предоставляется запрос на ввод нового пароля.
  • Пользователь вводит новый пароль, нажимает "ОК", и каждый живет счастливо после... до следующего раза!

Ответ 2

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

  • Пользователь переходит на страницу "забыл пароль" и вводит их имя пользователя или адрес электронной почты (в зависимости от того, что уникально), чтобы запросить пароль reset.

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

  • Найдите учетную запись пользователя. Сохраните временный пароль (обычно GUID) и отметку времени для записи учетной записи. Отправьте электронное письмо пользователю, содержащему временный пароль.

  • Пользователь либо нажимает на ссылку, содержащую временный пароль, и идентификатор пользователя в письме, либо переходит на страницу "забыл пароль", копирует и вставляет временный пароль и их идентификатор. Пользователь вводит новый пароль и подтверждает его.

  • Посмотрите на пользовательскую запись, и если текущее время находится в заданном временном интервале (например, 1 час) временной метки, сохраненной на шаге 2, затем хеш и сохраните новый пароль. (Очевидно, только если временные пароли совпадают!). Удалите временный идентификатор GUID и метку времени.

Принципиальным является то, что пользователь отправляет по электронной почте временный пароль, который позволяет им изменять свой пароль. Первоначально сохраненный пароль (он должен быть хэширован!) Никогда не изменяется на временный пароль, если пользователь его запоминает.

Исходный пароль никогда не будет отображаться пользователю, так как он должен быть хэширован и неизвестен.

Примечание Этот процесс полностью зависит от безопасности учетной записи электронной почты пользователя. Таким образом, это зависит от уровня безопасности, которого вы хотите достичь. Обычно этого достаточно для большинства сайтов/приложений.

Ответ 3

Пойду с:

  • Запросить адрес электронной почты, проверить электронную почту зарегистрирован
  • Создайте GUID и отправьте его по электронной почте
  • Пока не reset пароль
  • Пользователь нажимает ссылку, а затем вводит новый пароль
  • Reset пароль только после того, как пользователь находится на вашем сайте и нажал кнопку reset после ввода нового прохода.
  • Сделайте этот GUID более эффективным в течение короткого периода времени, чтобы сделать его более безопасным.

Ответ 4

Трой Хант делает несколько замечательных моментов в своей статье, Все, что вы когда-либо хотели знать о создании защищенного парольного reset функции. Наиболее релевантными выдержками являются:

[T] здесь два общих подхода:

  • Создайте новый пароль на сервере и отправьте его по электронной почте.
  • Отправить уникальный URL-адрес, который облегчит процесс reset

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

...

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

Когда мы говорим о URL reset, говорим об адресе сайта, который уникален для этого конкретного экземпляра процесса reset.

...

Что мы хотим сделать, так это создать уникальный токен, который может быть отправлен в электронном письме как часть URL-адреса reset, а затем сопоставлен с записью на сервере вместе с учетной записью пользователя, тем самым подтверждая, что владелец учетной записи электронной почты действительно является один пытается ввести пароль reset. Например, токен может быть "3ce7854015cd38c862cb9e14a1ae552b" и хранится в таблице вместе с идентификатором пользователя, выполняющего reset, и временем, в которое был создан токен (подробнее об этом в данный момент). Когда электронное письмо отправляется, оно содержит URL-адрес, такой как "Reset/? Id = 3ce7854015cd38c862cb9e14a1ae552b", и когда пользователь загружает его, страница проверяет наличие токена и, следовательно, подтверждает личность пользователя и позволяет пароль, который нужно изменить.

...

Другое, что мы хотим сделать с URL reset, - это ограничение времени на токен, чтобы процесс reset должен быть завершен в течение определенной продолжительности, например, в течение часа.

...

Наконец, мы хотим убедиться, что это одноразовый процесс. После завершения процесса reset токен должен быть удален, чтобы URL reset больше не функционировал. Как и в предыдущем пункте, это означает, что у злоумышленника очень ограниченное окно, в котором они могут злоупотреблять URL-адресом reset. Кроме того, конечно, токен больше не требуется, если процесс reset завершен успешно.

Он делает много других замечаний о том, как избежать утечки информации, CAPTCHA, двухфакторной аутентификации и, конечно же, основных передовых методов, таких как хеширование паролей. Я считаю важным отметить, что я не согласен с Трой о полезности вопросов безопасности, предпочитая Брюс Шнайер скептицизм практики:

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

Ответ 5

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

Воздерживаться от отправки любой личной информации, такой как пароли и информация о доходах, по электронной почте, поскольку она может стать ОЧЕНЬ ЭМБРАРОССИЕЙ для вас и вашей организации, если такая информация была пропущена или украдена. Подумайте о безопасности серьезно. Это просто один случай, когда все кирпичи упадут.

Что касается поиска пароля, внимательно прочитайте "Восстановить пароль" .

Суть в том, что приложение следует придерживаться пользователю reset свой собственный пароль. Вопросы личной безопасности должны быть используемый. Приложение не должно отправлять электронной почты, отображения паролей и временные пароли.

EDIT: обновленная ссылка

Ответ 6

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

  • Отображение половины временного пароля, когда идентификатор пользователя подтвержден (вопрос безопасности, адрес электронной почты и т.д.), а другая половина отправляется на учетную запись электронной почты. Если учетная запись электронной почты была скомпрометирована, маловероятно, что одному и тому же человеку также удалось выполнить атаку "человек в середине". (Видел на UK Goverment Gateway)

  • Подтверждение личности по электронной почте и другому средству - например, код, отправленный через текст зарегистрированному мобильному телефону. (Видно на eBay/PayPal)

Для тех, кто находится между этими двумя крайностями, реализация вопросов безопасности может быть способом, как упоминалось DaveG.

Ответ 7

Если вы включили адрес электронной почты с регистрацией. Кнопка "забыть пароль" отправляет электронное письмо на этот адрес электронной почты. Он гарантирует, что информация будет отправлена ​​на доверенное электронное письмо.

(Если база данных не взломана, но тогда ничего не безопасно).

Ответ 8

Вот три очень хорошие ссылки, которые предоставляют информацию о сбрасывании пароля:

Надеюсь, что это поможет. Они, несомненно, помогли мне понять эту проблему.

Ответ 9

Я бы применял уникальные адреса электронной почты через учетные записи.

Тогда просто отправить ссылку на временную страницу, которая позволяет человеку сменить пароль. (разрешить 24 часа или меньше)

Учетная запись электронной почты пользователя является самой слабой ссылкой в ​​этом сценарии.

Ответ 10

Никогда не отправляйте по электронной почте пароль пользователю. Даже если он автогенерируется. Лучший подход (рекомендуется и используется SANS и другими):

  • На странице забытого пароля спросите идентификатор электронной почты/пользователя и НОВЫЙ пароль от пользователя.
  • Отправить ссылку на сохраненную электронную почту для этой учетной записи с активацией ссылка.
  • Когда пользователь нажимает на эту ссылку, включить новый пароль.

Если он не нажимает ссылку в течение 24 часов или около того, отключите ссылку (чтобы она больше не меняла пароль).

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