A good password reset flow helps a person regain access without revealing whether an account exists. It gives clear next steps, uses a short-lived reset link or code, and explains what happened after a new password is set.
This is a small product flow with a large trust cost when it fails. The copy, security checks, and failure states need to agree.
Start with one clear request screen
Ask for the email address or account name your product uses. Label the field plainly and allow password managers and paste. Put the reset action where a person expects it from sign-in.
After submission, show a message such as: “If an account matches, we'll send a reset link. Check your inbox and spam folder.” Give a route back to sign-in and help for someone who no longer has access to that inbox.
The OWASP Forgot Password Cheat Sheet recommends a consistent message for existing and non-existing accounts and similar response times. An error that says “No account found” can help someone probe for registered users.
A neutral message does not require vague help. Tell the person what to look for, how long to wait before retrying, and where to get support. Make those times reflect your actual service.
Treat the link as a limited key
A reset link or code should be single-use, expire after an appropriate period, and be generated and stored securely. OWASP describes those controls in its recovery guidance. The email should send the person to your own service, not ask them to reply with a password.
The GOV.UK password pattern also advises using a time-limited reset link or code and notifying the person when a password reset has happened. Do not email the new password.
Write the expired-link screen before it happens. “This link has expired. Request a new one” is more useful than a generic “Invalid token.” If a newer request replaced an older link, explain the next safe action without exposing account details.
Make the new-password screen usable
Tell people the actual password rules before they submit. Let them paste from a password manager, and provide a way to show or hide the value if that fits the product. Keep focus order clear and identify errors next to the affected field.
Do not force a surprising new rule only after someone has typed and submitted a password. If confirmation is required, explain mismatches without clearing both fields unnecessarily.
The reset should not silently sign someone into a session unless your security design specifically supports that. OWASP recommends the normal sign-in path after reset and considering existing-session handling. Show a success state with a clear “Sign in” link and send a separate account notification.
Test the cases that usually get missed
Use test accounts and disposable tokens. Check:
- A real and an unknown email get the same public response.
- A valid link works once; a second use is rejected clearly.
- An expired link offers a safe restart.
- A new password that fails the policy gets a useful error.
- A network failure does not claim the reset succeeded.
- The notification goes to the right address and contains no password.
- Keyboard and screen-reader users can finish the whole flow.
This test list is a starting point, not a security audit. Review rate limits, logs, token handling, and session rules with the people responsible for authentication.
Keep support connected to the flow
Some people have lost access to the email or phone on the account. Give them a visible support path with a careful identity-check process. Do not ask for secrets in an open form or promise recovery the team cannot provide.
The final check is simple: Can a real user recover access, and does every visible state tell the truth about what happened? Fix any mismatch before polishing the illustration on the request page.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
