2

Я перепрограммирую функциональность «сбросить пароль» для следующей версии моего user management system. Как это работает в настоящее время:Страница восстановления забытого пароля: нужно ли пользователю вводить имя пользователя и адрес электронной почты?

  1. Пользователь вводит свое имя пользователя и адрес электронной почты.
  2. Если эта информация верна, в базе данных создается и сохраняется случайный токен, а ссылка на токен отправляется на адрес электронной почты пользователя в файле.
  3. Пользователь щелкает по ссылке, с возможностью «подтвердить» или «отклонить» запрос на сброс.
  4. Если они подтверждают запрос на сброс, они должны ввести свой адрес , а также их новый пароль (и повторить также новый пароль). Это отправляется на сервер вместе с токеном. Если адрес электронной почты совпадает с маркером, а запрос на сброс еще не истек, пароль обновляется.

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

+0

Не могли бы вы просто закодировать адрес электронной почты в ссылке, которая была отправлена ​​пользователю? Тогда пользователю не нужно вводить ничего, кроме нового пароля. –

+0

Действительно, я мог бы - вопрос в том, что * должен * я? – alexw

+2

Требование электронной почты, по-видимому, касается использования, когда злоумышленник знает (или может угадать) токен, но не знает адрес электронной почты. Если злоумышленник получает маркер из электронной почты пользователя, злоумышленник определенно знает адрес электронной почты. Кодирование адреса электронной почты в URL-адресе, отправленном пользователю, похоже, не дает злоумышленнику никакой информации, которую они не имели бы. Возможно, вы захотите запустить это с помощью security.se –

ответ

2

Я не вижу никакой ценности при этом. Просто сделайте свой ключ безопасным. Возможно, 128-битный (это 22 кодированных символа с базой 64) защищен случайным образом. Это кажется достаточно большим. Также добавьте тайм-аут в течение срока действия токена. 24 часа - прекрасный компромисс между безопасностью и неудобствами.

Мне нравится идея добавления адреса электронной почты в токен, чтобы вы могли вести журнал ошибок более разумно.