Password Reset

Overview

This page contains recommendations for the implementation of password reset functionality.

General

  • Implement a password reset in one of the following ways:

  • During password reset do not indicate if a user with entered data exists or not. Ask for a username/email address/phone number/etc. and inform the a that if there is a user with the data entered, reset recommendations will be sent to them via the appropriate communication channel.

  • Only block an old password after a user has successfully passed the password reset step.

  • Do not automatically sign a user in. Once a user sets their new password, log out a user and send them to a usual login mechanism (with multi-factor authentication, if enabled).

  • Terminate all active sessions after the password reset. You can explicitly ask a user if they want to invalidate all of their existing sessions.

  • During password reset, request at least the following data:

    • New password.

    • Confirmation of the new password.

  • Link a random token (or one-time password) to an individual user in a database.

  • Do not reveal a current password in any way during the password reset.

  • Do not reveal a random token (or one-time password) in any way during the password reset.

  • Log successful and failed password reset attempts, see the Logging and Monitoring page.

  • Comply with requirements from the Error and Exception Handling page.

Password reset based on a URL token

  • Send a password reset URL to a user and pass a random token in the query string of the URL. For example:

    https://website.local/account/password/reset?token=GiOzXAwlZ17NsW4CkVV8MQXtiQN9cWiY

  • Generate a random token using a cryptographically strong random generator, see the Cryptography: Random Generators page.

  • Use random tokens of length 32+ bytes.

  • Set a short expiration time for a random token (~ 24 hours).

  • Use a random token once. Delete a random token or transfer it to a final status that prohibits reusing.

  • Do not rely on the Host HTTP header while creating the reset URLs to avoid the Host Header Injection attack. Either hardcode the URL or validate against a list of trusted domains using an allow list.

  • Add the Referrer-Policy HTTP header with the noreferrer value to the reset password page in order to avoid referrer leakage.

Password reset based on a one-time password

Password reset based on a time-based one-time password

References

PreviousPassword PolicyNextPassword Storage

Last updated