Password Reset Vulnerabilities: Common Patterns

Password reset is one of the most sensitive features in a web application.

It looks simple: a user forgets a password, requests a reset link, receives a token, sets a new password, and logs in again. From a security perspective, however, password reset is an alternative authentication path. If an attacker can abuse it, they may not need the original password at all.

A strong login page does not matter much if the recovery flow is weak.

This article explains common password reset vulnerability patterns from a web pentesting perspective.

Image: Type: Context. Mô tả: “A simple flow diagram showing user requests password reset, application generates token, email is sent, user sets new password.” caption: “A password reset flow is an authentication flow with a different entry point.”

Context

A password reset flow typically includes several steps:

  1. The user submits an email or username.
  2. The application checks whether the account exists.
  3. The application generates a reset token.
  4. The token is sent to the registered email address.
  5. The user opens the link and sets a new password.
  6. The application invalidates the token and updates the credential.

Each step introduces a possible attack surface.

A pentester should not only check whether the reset link works. The real question is: can an attacker influence, predict, reuse, intercept, or misdirect the recovery process?

Root Cause

Most password reset vulnerabilities come from one of these design mistakes:

  • The application treats password reset as a support feature instead of a security-critical authentication flow.
  • Reset tokens are weak, reusable, long-lived, or not bound to the correct account.
  • The flow leaks whether an account exists.
  • The application trusts user-controlled input when building the reset link.
  • The reset process fails to invalidate old sessions or old tokens.
  • Password policy is inconsistent between registration, password change, and password reset.

In short, the application allows untrusted data or weak state management to influence account recovery.

Common Vulnerability Patterns

1. Account Enumeration

Account enumeration occurs when the application reveals whether an email or username exists.

For example:

  • Existing account: We sent you a reset link.
  • Non-existing account: This email is not registered.

This may look harmless, but it allows an attacker to build a list of valid users. In targeted attacks, this is useful for phishing, credential stuffing, and social engineering.

A safer response is generic:

If an account exists for this email, a reset link will be sent.

However, the application must also avoid side-channel leaks such as response time differences, status code differences, or different redirect behavior.

Image: Type: Test case. Mô tả: “Two password reset responses side by side: one for an existing account and one for a non-existing account, showing why different messages leak information.” caption: “Different responses can expose valid accounts.”

2. Weak or Predictable Reset Tokens

A reset token must be cryptographically strong. If the token is short, sequential, timestamp-based, or derived from predictable user data, it may be guessable.

Examples of weak token design include:

  • Incremental numeric IDs
  • Base64-encoded user IDs
  • Tokens derived only from email and timestamp
  • Short random strings
  • Tokens generated using insecure randomness

A secure reset token should be high-entropy, random, single-use, and stored server-side in a hashed form if possible.

3. Token Reuse

A reset token should become invalid immediately after use.

If the same token can be used multiple times, an attacker who obtains the link once may reset the password again later. This can also create confusing account recovery behavior where old emails remain dangerous.

Test safely in a lab by using a reset link once, then attempting to reuse the same link. The expected behavior is that the second attempt fails.

4. Long Token Expiration

Password reset tokens should have a short lifetime. A token that remains valid for days or weeks increases the risk window if an email inbox is compromised or a reset link is logged somewhere.

There is no universal expiration time for every application, but the principle is clear: the token should be valid long enough for legitimate recovery, but not longer than necessary.

Some applications build password reset URLs based on request headers such as Host or X-Forwarded-Host.

If these headers are not validated, an attacker may be able to make the application generate a reset link pointing to an attacker-controlled domain.

The user receives a legitimate email from the real application, but the link may lead elsewhere.

This is dangerous because the attack abuses trust in the application email itself.

Image: Type: PoC. Mô tả: “In Burp Suite Repeater, show a password reset request where the Host header is modified in a lab environment, and the generated reset link reflects the modified host.” caption: “Reset link generation must not trust user-controlled host headers.”

6. Password Reset Token Not Bound to the Correct Account

In some broken implementations, the reset token is valid but the account being updated is controlled by a parameter in the request body.

For example, the reset form may submit:

POST /reset-password
token=VALID_TOKEN&email=victim@example.com&new_password=...

If the application validates only the token but trusts the email parameter, the reset may apply to the wrong account.

The secure design is to bind the token server-side to a specific account and never trust the account identifier from the client at the final password update step.

7. Missing Session Invalidation

After a password reset, old active sessions should usually be invalidated or at least reviewed.

If a user resets a password because of suspected compromise, but the attacker remains logged in through an existing session, the reset has not fully solved the problem.

For sensitive applications, password reset should trigger:

  • Session rotation
  • Logout from other devices
  • Notification to the user
  • Optional review of recent login activity

8. Inconsistent Password Policy

The password policy should be consistent across registration, password change, and password reset.

A common mistake is enforcing strong passwords during registration but allowing weak passwords during password reset. This creates a downgrade path.

The reset flow should use the same password strength rules as the rest of the authentication system.

Impact

Password reset vulnerabilities can lead to:

  • Account enumeration
  • Account takeover
  • Credential stuffing support
  • Phishing enablement
  • Long-term unauthorized access
  • Loss of trust in authentication controls

The impact depends on the application. For a simple forum account, the risk may be moderate. For banking, SaaS admin panels, healthcare, or internal enterprise portals, the impact can be critical.

Signature

Look for these signals during testing:

  • Different response messages for valid and invalid accounts
  • Reset tokens that are short or predictable
  • Reset links that remain valid after use
  • Reset links that stay valid for too long
  • Reset URLs reflecting the Host header
  • Reset form containing editable user identifiers
  • Password reset does not invalidate existing sessions
  • Password policy weaker than registration or password change
  • No notification after password reset

How to Test Safely

Only test password reset flows in applications where you have authorization.

A safe test approach:

  1. Create two test accounts that you control.
  2. Request password reset for account A.
  3. Observe the reset email, token structure, expiration, and link format.
  4. Try to reuse the token after a successful reset.
  5. Check whether account identifiers can be modified.
  6. Test whether the response leaks account existence.
  7. Check whether old sessions remain valid after reset.
  8. Confirm whether password policy is consistent.

Do not test against real user accounts unless the scope explicitly allows it.

Image: Type: Test case. Mô tả: “A checklist table for password reset testing with columns: test case, expected secure behavior, result.” caption: “Password reset testing should be structured and controlled.”

Remediation

A secure password reset flow should include:

  • Generic responses for reset requests
  • Strong random reset tokens
  • Short token expiration
  • Single-use tokens
  • Server-side token-to-account binding
  • No trust in user-controlled account identifiers
  • Validated canonical domain for reset links
  • Consistent password policy
  • Session invalidation after reset
  • User notification after successful password reset
  • Logging and monitoring for abnormal reset attempts

References

Final Thoughts

Password reset is not a secondary feature. It is a second door into the account.

If that door is weak, attackers do not need to break the main login flow.

A mature security review should always include password reset testing as part of authentication testing.

Need help reviewing your authentication and account recovery flows? KevinSec provides practical web application security reviews focused on real-world account takeover risks, authentication weaknesses, and business-impact findings.