Does Your Password Reset Actually Work — or Only in Testing?
Seven red flags reveal whether account recovery safely restores access or quietly creates support cost, abandonment, and security exposure.
A user cannot remember their password. That sounds like a small support problem.
For an online shop, customer portal, or SaaS product, that moment can decide whether the person returns, opens a support ticket, or quietly moves to a competitor. At the same time, password reset is one of the most sensitive public functions in an application: it must restore access for a legitimate user without revealing which accounts exist or creating an easier route for attackers.
The problem is rarely that there is no reset link. The problem is that nobody regularly tests the complete journey as a real user.
The reset works — until somebody actually needs it
Many tests stop too early:
- The form accepts an email address.
- The API responds with 200.
- A message appears in a local mail catcher.
- A developer completed the flow once.
That does not prove that a real user can recover an account in production. The email may land in spam, the link may contain the wrong domain, a proxy may damage the token, the token may expire before delivery, or the success screen may claim completion although the backend operation failed.
Monitoring that only checks whether the login page responds will detect none of this.
A security control and a conversion journey
OWASP recommends consistent responses for existing and non-existing accounts, short-lived single-use tokens, and controls against automated request flooding. These measures reduce account enumeration, brute-force attempts, and inbox flooding.
There is a product dimension too: the process must be understandable, deliverable, and usable on mobile devices.
A secure reset that legitimate users cannot complete creates support cost and churn. A convenient reset with weak token or session handling creates security exposure. Both sides need to be tested together.
Seven red flags you can test yourself
1. Different responses reveal valid accounts
If an unknown address immediately produces “No account found,” third parties can build a list of registered users. A consistent response such as “If an account exists for this address, a message has been sent” is safer. Large differences in response time can leak the same information.
2. Reset emails are technically sent but practically undeliverable
Do not test only with your company inbox. Check several major mailbox providers, mobile clients, and forwarded addresses. Review SPF, DKIM, DMARC, the visible sender, the link domain, and the clarity of the message. An email in an application log is not necessarily a delivered email.
3. Tokens live too long or can be reused
Reset tokens should be random, sufficiently strong, stored securely, linked to one account, time-limited, and invalid after use. Deliberately test the same link twice, an expired link, a modified token, multiple links requested in sequence, and a link after the password was changed.
4. Existing sessions are ignored
After a password change, the product needs an explicit decision about active sessions. OWASP recommends notifying the user and either invalidating sessions or giving the user a clear option. A new password achieves little if an attacker can continue using an old authenticated session.
5. The form fights password managers
Browsers and password managers can only assist when fields are labelled correctly. MDN documents autocomplete="new-password" for a new password and autocomplete="one-time-code" for one-time verification codes. Missing or incorrect values can trigger confusing autofill and avoidable abandonment, especially on mobile.
6. MFA recovery was never designed
A person who forgot a password may also have lost access to the second factor. Password reset and full account recovery are therefore not always the same process. NIST treats account recovery as a separate, risk-based process and describes methods such as recovery codes, recovery contacts, or repeated identity proofing. An undocumented support override invented during an incident is not a reliable recovery method.
7. Nobody notices when a release breaks the journey
Changes to routing, email templates, authentication providers, domains, cookies, or session handling can silently break recovery. A regular synthetic test should request a reset for a test account, receive the email, open the link, set a new password, sign in, confirm that token reuse is rejected, and verify the intended session behaviour.
What a practical audit should inspect
A Website-Pflichtencheck review would look beyond the visible form. Relevant controls include consistent responses, rate limits, token generation and expiry, redirects and production domains, email deliverability, mobile usability, password-manager compatibility, session invalidation, MFA recovery, safe logging, and end-to-end monitoring.
The most important test is simple: Can a real person safely recover their account today without a developer stepping in?
When the answer is based on assumptions, password reset is not a finished feature. It is a quiet operational risk. A focused review costs far less than a wave of locked-out users or a recovery process designed for the first time during a security incident.