How do I handle password resets and account recovery securely?

Secure password resets and account recovery are mostly about proving control of the account without creating a new attack path.

Core principles

• Treat recovery as high-risk authentication
• Minimize what can be changed through recovery
• Prefer short-lived, single-use links/tokens
• Use multiple signals and step-up checks for sensitive changes
• Avoid revealing whether an account exists

Password reset best practices

1) Use a reset token, not the old password

• Generate a random, cryptographically secure token
• Make it single-use
• Expire it quickly, typically 15–60 minutes
• Store a hashed version of the token server-side if possible

2) Deliver the token through a verified channel

• Commonly via email
• Prefer channels already bound to the account
• Never send the new password by email
• Include a clear warning if the request wasn’t initiated by the user

3) Don’t disclose account existence

• The reset request response should be generic:
  • “If an account exists, we’ve sent instructions.”
• This prevents user enumeration

4) Invalidate existing sessions after reset

• After a successful password reset:
  • Revoke active sessions
  • Revoke refresh tokens
  • Invalidate “remember me” tokens
• Consider notifying the user of the reset

5) Rate-limit and monitor

• Limit reset requests per account, IP, and device
• Detect suspicious bursts and automation
• Log reset attempts and completions

Account recovery best practices

1) Prefer recovery factors over knowledge-based questions

Avoid security questions like:

• Mother’s maiden name
• First pet’s name
• Favorite teacher

These are often guessable or discoverable. Better options:

• Backup email
• Backup phone number
• Authenticator backup codes
• Recovery keys
• Trusted device confirmation

2) Use step-up verification for sensitive recovery

If the user wants to:

• Change email
• Change phone
• Disable MFA
• Replace recovery factors

Require stronger verification, such as:

• Existing MFA
• Recent login
• Email + device confirmation
• Additional identity checks for high-risk accounts

3) Make recovery channels separate from primary login

• Keep recovery email/phone distinct from primary sign-in where possible
• Let users review and update recovery methods securely
• Encourage backup codes when MFA is enabled

4) Add delays for high-risk changes

For risky recovery actions:

• Send notification to all known channels
• Introduce a cooldown period before changes take effect
• Allow the user to cancel if the change was fraudulent

If the user loses access to everything

For truly lost access:

• Use a carefully designed manual recovery process
• Require stronger identity proofing only when necessary
• Avoid over-collecting PII
• Have a fraud review path for suspicious cases

Examples of stronger recovery proof:

• Government ID check, if appropriate and lawful
• Prior payment instrument verification
• Historical account evidence
• Support agent review with anti-social-engineering procedures

Important security details

• Use TLS everywhere
• Protect against CSRF on reset forms
• Ensure tokens are bound to:
  • account
  • expiration time
  • maybe client/session context where appropriate
• Make tokens unguessable and long enough
• Never log full reset tokens
• Prevent open redirects in reset URLs
• Ensure the “set new password” page cannot be used with a stale or reused token

UX recommendations

• Tell users what to expect after reset
• Show clear security notifications
• Provide a way to report unauthorized resets
• Encourage MFA and backup codes during onboarding

A solid reset flow example

1. User requests reset
2. System responds generically
3. Email with single-use token is sent
4. User opens link and sets a new password
5. System verifies token, rate limits, and expiry
6. Password is updated
7. Existing sessions are revoked
8. User is notified across known channels

A solid recovery flow example

1. User cannot access primary factor
2. System offers verified recovery methods
3. If those fail, step-up checks are required
4. High-risk changes are delayed and notified
5. Support-assisted recovery is tightly controlled

If you want, I can also give you:

• a secure reset flow diagram
• sample backend logic
• or a checklist for implementing this in your app