Home / Knowledge hub / Password reset flaw
Knowledge hub
Password reset flaw
A weak reset link or code that lets someone else take over the account.
What it means
A password reset flaw is any weakness in the "forgot password" flow that lets someone other than the owner set a new password or take over the account. The flow is an alternative way in, so it has to be at least as strong as signing in.
The flaw can be in the token (guessable, reused or never expiring), in how the link is built (using a header the attacker controls), in what the response reveals, or in the steps around it, such as accepting a reset for a different account than the one the link was sent to.
Why it matters
A reset flaw skips the password entirely. The attacker needs no stolen credentials and no phishing, only a weakness in a page you published. The result is full account takeover, and if the target is an admin, much more than that.
It also tends to be found late, because the flow works for normal users and is rarely re-tested after changes. Support teams add shortcuts, such as showing a reset link in the admin panel, and those become part of the attack surface.
How it shows up
You meet it in the reset email, the token in the link, the page that sets the new password and the API behind it. Check that the token is long, random and from a secure random generator, stored only as a hash, valid once, and expires soon. Check that using it signs out other sessions.
Repeating mistakes: tokens built from time or user id; the link built from the Host header so a poisoned request sends the link to the attacker's domain; the token returned in the API response; no limit on attempts; the new password accepted without the token being re-checked; and different replies for known and unknown emails.
Questions people ask
Password reset flaw, answered
What makes a reset token safe?
It should be random and long, tied to one account, usable once and short-lived. Store only a hash of it, and cancel it when a new one is issued or the password changes.
What is host header poisoning in a reset flow?
If the app builds the reset link from the request's Host header, an attacker can set that header to their own domain. The victim then receives a genuine email whose link goes to the attacker.
Should the reset page say whether the email exists?
No. Give the same message either way, such as "if that address has an account, we have sent a link". Otherwise it leaks which people use your service. See [[account-enumeration]].
Should we sign the user in after a reset?
Many teams do not, and ask them to sign in with the new password, which keeps the flow simple. Whatever you choose, end the user's other sessions and tell them by email.
How do we test a password reset flow?
Request several tokens and look for patterns. Reuse a token, use an old one after a new request, change the account id in the final step, and alter the host header. Each should fail.
Sources
Where this comes from
Related
Terms that sit next to this one
Account takeover
An attacker ends up signed in as one of your real users.
Account enumeration
Learning which emails have accounts because your app answers differently.
Credential recovery
The ways a locked-out user gets back in, which are often the weakest door.
Magic link
A sign-in link sent by email that replaces the password for that visit.
CSPRNG
A random number generator safe to use for secrets, tokens and keys.
Is reset as strong as sign-in?
We test your reset and recovery flows for guessable, reusable and misdirected links, and show each takeover with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.