Q7 of 22 · Scenarios

How would you test a password reset flow?

ScenariosJuniorscenariopassword-resetsecurityauthenticationfunctional

Short answer

Short answer: Clarify token expiry time, one-time use policy, and session invalidation on reset. Then cover the full happy path, token security, account enumeration prevention, and recovery after reset.

Detail

Clarify first

  • How long does the reset token/link remain valid?
  • Can the same token be used more than once?
  • Does resetting the password invalidate all existing active sessions?
  • Is the flow email-based, SMS OTP, or security questions?

Functional

  • Valid email address → reset email delivered within a reasonable time
  • Reset link opens correctly and allows password change
  • New password that meets strength requirements is accepted; account login works with new password
  • Old password is rejected after the reset completes
  • If policy prevents reuse, the previous password is rejected as the new one

Negative / error handling

  • Unregistered email address → same success-like response as a valid email (no enumeration: "If this email exists, a reset link has been sent")
  • Expired token → clear message; user prompted to request a new link
  • Already-used token → rejected; user prompted to request a new link
  • New password below the strength threshold → field-level validation, link not consumed
  • Multiple reset requests in quick succession → only the most recently issued token is valid; earlier tokens invalidated

Edge & boundary

  • Reset link clicked in a different browser or device than where it was requested
  • Account locked during the reset flow — should reset still work or require unlock first?
  • Email has case variants (Alice@example.com vs alice@example.com) — treated as the same account?
  • Reset link used after the account is deactivated

Security

  • Reset token has sufficient entropy (not sequential or guessable)
  • Token transmitted only in the email link, not in a query string that appears in Referer headers
  • Resetting the password terminates all other active sessions (session invalidation on password change)
  • Brute-forcing the token prevented by short expiry plus rate limiting

Close: automate token expiry, reuse prevention, account enumeration check (assert same HTTP response for valid and invalid emails), and session invalidation via DB query. Keep manual for email delivery timing and mobile link behavior.

// WHAT INTERVIEWERS LOOK FOR

Account enumeration prevention is the key signal. Also: token entropy, session invalidation on reset, and multiple rapid requests invalidating earlier tokens.

// COMMON PITFALL

Testing only that a valid email gets a link and the link works. Missing enumeration prevention, token reuse, session invalidation after reset, and brute-force protection on the token.