Password Reset Token Does Not Expire: An Insecure Configurability Issue

Learn how an expired password reset token vulnerability can affect account security. This article explains the Insecure Configurability issue, how password reset tokens should work, and why tokens that never expire can create serious security risks in web applications.

Introduction

Password reset functionality is one of the most sensitive parts of an application. A password-reset link usually contains a temporary token that allows a user to set a new password. For security, these tokens should normally have a limited lifetime and should become invalid after the relevant account state changes. While testing an authorized application, I came across an interesting behavior: a previously generated password-reset token could still be used even after changing the account's email address.

What is the issue? :

When a user requests a password-reset link, the application generates a token and sends it to the registered email address. A secure flow may look like:

Request password reset
Temporary token generated
Token sent to email
Password reset
Token becomes invalid

Request password reset
Temporary token generated
Token sent to email
Password reset
Token becomes invalid

The interesting question is:

What happens to an unused password-reset token when the account's security-related information changes? If the previously generated token remains valid when it should have been invalidated, this can indicate an issue with password-reset token lifecycle management.

Step to Reproduce

The behavior can be tested using your own account on an authorized target.

1. Create an Account Create a normal account on the target application.

2. Request a Password Reset Request a password-reset link. The application should send a reset link to the registered email address. Do not use the link yet.

3. Log In Normally Instead of using the password-reset link, log in using your existing password.

4. Change the Account Email Change the account's email address to another email address that you control. At this point, the account's security-related information has changed.

5. Test the Previously Generated Token Now return to the password-reset link that was sent to the original email address. Use the link with your own test account and observe whether the application still allows you to set a new password. If the old token remains usable when the application's intended security model requires it to be invalidated, this may represent a password-reset token invalidation issue.

Why Could This Matter ?

Password-reset tokens are effectively temporary credentials. If a token remains valid longer than intended, an attacker who obtains an old reset token may potentially use it later. The actual impact depends on several factors:

• How long the token remains valid
• Whether the token is single-use
• Whether changing account information invalidates existing tokens
• Whether the token can still reset the password
• Whether an attacker could realistically obtain the old token Therefore, the security impact should be demonstrated rather than assumed.

What Should Happen?

A secure implementation should carefully manage password-reset tokens. Depending on the application's design, tokens may need to be:

• Short-lived
• Single-use
• Invalidated after successful password reset
• Invalidated after relevant account-security changes
• Cryptographically unpredictable
• Properly associated with the intended account The exact behavior can vary between applications, but sensitive recovery tokens should never remain usable indefinitely. Don't Confuse This With Token Expiration There is an important distinction between time-based expiration and state-based invalidation. A token might have a lifetime of 30 minutes, for example, but that doesn't necessarily mean it should remain valid throughout those 30 minutes regardless of what happens to the account. Security-sensitive events may require the application to invalidate previously issued tokens before their normal expiration time. That's why testing token behavior after account changes can reveal interesting security issues.

Responsible Testing

This type of testing should only be performed against:

• Your own accounts
• Authorized security-testing environments
• Bug bounty programs that explicitly allow the test Never attempt to use another person's password-reset token or access an account you do not own.

Final Thoughts

Password-reset functionality is often overlooked during security testing, but it is an important part of an application's authentication system. A simple question such as: "Is an old password-reset token still valid after an important account change?" can reveal weaknesses in token lifecycle management. The key is not just finding that a token works. A good security assessment should determine why it remains valid, what security boundary it affects, and what realistic impact it creates. Always test responsibly, document the behavior clearly, and report the issue through the appropriate security channel.