Overview
Password reset flows are a frequent weak point: they exist to help legitimate users regain access, but a poorly designed reset can hand an account to an attacker. This lesson covers secure password-reset design.
Learning objectives
- Describe a secure password-reset flow.
- Identify common reset-flow vulnerabilities.
- Explain the security properties reset tokens must have.
Core concept
A secure reset flow lets a user prove control of their account (usually via a registered email) and set a new password, without leaking information or granting an opening to attackers. Requirements:
- Send a reset link containing a secure, random, single-use token with a short expiration.
- Do not reveal whether an email/username exists (generic "if the account exists, a link was sent").
- Invalidate the token after use and invalidate existing sessions on reset.
- Do not expose the token in logs/referrers, and deliver it only to the verified channel.
How it works
On request, the server generates an unpredictable, single-use token tied to the account, stores it with an expiry, and emails the reset link. Clicking it proves control of the inbox; the user sets a new password; the token is then invalidated. Unpredictable tokens prevent guessing; single-use + short expiry limit the window; generic responses prevent account enumeration; session invalidation on reset locks out anyone using a hijacked session. The reset must also verify the token belongs to the account being changed to prevent tampering.
Practical example
Alice requests a reset; the site responds "if an account exists for that email, a reset link has been sent" (revealing nothing), and emails a link with a long random token valid for, say, 30 minutes and usable once. Alice sets a new password; the token is consumed and all her existing sessions are invalidated. A weak flow might use a guessable/predictable token, never expire it, reveal whether the email exists, or fail to bind the token to the account — each an exploitable flaw.
Cybersecurity relevance
Reset flows are a common account-takeover vector: predictable/leaked tokens, no expiration, host-header poisoning of the reset link, account enumeration via differing responses, and missing session invalidation are recurring findings. Because a reset can set a new password, flaws here can fully compromise accounts. Testers scrutinize token randomness, expiry, single-use, response uniformity, and link generation; defenders implement each control. Reset security ties back to session invalidation (logout lesson) and enumeration defenses (login lesson).
Common mistakes
- Predictable or non-expiring reset tokens, enabling guessing or replay.
- Revealing whether an account exists through the reset response.
- Not invalidating the token after use or sessions after reset.
Key takeaways
- A secure reset uses an unpredictable, single-use, short-lived token delivered to the verified channel, with generic responses that do not reveal account existence.
- Invalidate the token after use and existing sessions on reset; bind the token to the correct account and keep it out of logs/referrers.
- Reset flows are a common account-takeover vector (weak tokens, no expiry, enumeration, missing invalidation) and a key assessment focus.
Check your understanding
- What properties must a password-reset token have to be secure?
- Why should a reset request give a generic response regardless of whether the account exists?