Password Login vs Password Reset: Which One Is the Real Authentication System?

Imagine a banking website with an extremely secure login system.

Strong password requirements? Check.

Multi-factor authentication? Check.

Rate limiting? Check.

Account lockouts, suspicious login alerts, CAPTCHA? All there.

You try guessing passwords, but the application blocks you after a few attempts. You try logging in without completing MFA, but every protected endpoint rejects you.

Everything looks solid.

Then you notice a small link sitting right below the login button.

Forgot Password?

You click it.

And suddenly, you're looking at an entirely different way to gain control of an account.

Here's the question that makes password recovery so interesting:

What good is a heavily protected login page if the password reset functionality lets someone take over the same account?

This doesn't mean password reset is always less secure than login. A properly designed recovery process can be extremely strong.

But when it's implemented badly, it can undermine protections that developers spent months building.

Let's look at why.

Two different doors to the same account

Think about how a normal login works.

You enter your username and password.

The server checks your credentials.

If they're correct, you might need to complete an additional step, such as entering a one-time code or using a passkey.

Once you've satisfied the required checks, the application creates an authenticated session.

Straightforward.

Now think about what happens when you forget your password.

You can't provide the password because, well, you've forgotten it.

So the application needs another way to verify that you're the rightful account owner.

Usually, that involves sending a password reset link or code to your registered email address.

You open the link, choose a new password, and regain access to your account.

Sounds reasonable.

But notice something.

The password reset functionality can change the very credential that the login system trusts.

That's a powerful capability.

And whenever an application allows someone to replace an authentication credential, the process deserves serious security testing.

Let's look at a normal password reset request

Suppose you have an account on example.com.

You've forgotten your password, so you click "Forgot Password" and enter your email address.

Your browser sends: POST /forgot-password

With the request body: email=alice@example.com

The server receives the request, generates a password reset token, and emails a link to Alice.

Something like: https://example.com/reset-password?token=a8f29c...

When Alice opens the link, the application should verify that the token is valid.

It should also know which account the token belongs to.

After Alice submits her new password, the server should update only the account associated with that valid token.

If that's what happens, great.

But what if the server doesn't properly connect the token to the account being updated?

That's where things can go very wrong.

One small parameter can change everything

Consider a deliberately vulnerable application in a security lab.

You request a password reset for your own account.

You receive a reset link, open it, and enter a new password.

Your browser sends the following request: POST /reset-password

Request body: token=abc123&username=alice&new_password=NewPassword123

At first glance, nothing seems unusual.

There's a token, a username, and a new password.

But take a closer look at the username parameter.

Why is the browser telling the server which account to update?

Shouldn't the server already know that from the reset token?

There's nothing inherently wrong with sending a username alongside a token, provided the server independently verifies that the token authorizes a reset for that exact account.

The problem begins when the server blindly trusts the username supplied by the client.

Imagine changing username=alice to username=bob

If the server accepts Alice's reset token but changes Bob's password, you've found a serious authentication flaw.

You didn't guess Bob's password.

You didn't defeat his login rate limit.

You didn't need to know his existing credentials.

You found a weakness in the recovery process that allowed an unauthorized password change.

And depending on the application's other security controls, that could lead to account takeover.

This isn't just a hypothetical category of vulnerability. PortSwigger has a Web Security Academy lab called Password Reset Broken Logic that demonstrates this kind of mistake.

The lesson from that lab is worth remembering:

A password reset token must authorize a reset for one specific account. It cannot simply act as a generic permission slip to change any password.

But doesn't a password reset link need a token?

Absolutely.

And this is another area where the implementation matters far more than the appearance.

Imagine receiving this link: https://example.com/reset-password?token=123456

Six digits.

Is that automatically vulnerable?

Not necessarily. You would need to consider expiration, rate limiting, how the code was generated, and other protections.

But a small code space can create a serious problem if attackers can make enough guesses.

Now consider a long, cryptographically random reset token.

That's considerably harder to guess.

However, unpredictability isn't the only requirement.

A secure reset token should have several properties:

• Unpredictable: It should be generated using a cryptographically secure random number generator.
• Account-bound: It must be associated with the correct account.
• Short-lived: It should expire after an appropriate period.
• Single-use: Once the reset succeeds, the token should no longer work.
• Protected: It should be transmitted over HTTPS, securely stored, and protected from unnecessary exposure.

Why does single-use matter?

Imagine you've already reset your password, but the same link still works tomorrow.

Anyone who obtains that link while it's valid could potentially use it to change your password again.

A recovery token is a temporary credential. It shouldn't remain useful indefinitely.

And don't forget where these links appear.

They often contain tokens in URL query parameters. That's a normal design for email-based password recovery, but it means developers need to prevent token leakage through things like referrer headers, logs, and third-party content.

A secure implementation takes those risks seriously.

What about multi-factor authentication?

Now here's where the discussion gets even more interesting.

Suppose your account has MFA enabled.

Even if someone knows your password, they still need your second authentication factor to sign in.

That's exactly what MFA is supposed to achieve.

But what happens during account recovery?

What if you lose your phone?

What if you can no longer access your authenticator app?

The application needs a way to help legitimate users recover their accounts.

And that creates another security-sensitive workflow.

Some systems require backup codes, an existing trusted authenticator, or additional identity verification before allowing users to reset MFA.

Others may provide weaker recovery options.

If an attacker can exploit a weak recovery process to remove or replace the second factor, the protection offered by MFA can collapse.

MFA is only as effective as the systems that enforce and recover it.

One important detail: successfully resetting someone's password doesn't necessarily bypass their MFA.

If the application still requires the legitimate second factor at login, the attacker may remain locked out.

That's why account recovery needs to be examined as a complete workflow, not just one request.

The real question is whether a recovery path allows an unauthorized person to regain access or weaken the account's security requirements.

How I would test password reset functionality

Let's get practical.

Suppose you're testing a web application in an authorized lab or bug bounty program.

You have Caido installed, and you can create two test accounts.

We'll call them Alice and Bob.

You don't need a large wordlist or thousands of requests to begin.

You need to understand how the recovery process works.

Step 1: Request a password reset

Log out of Alice's account.

Click "Forgot Password," enter Alice's email, and capture the request in Caido.

Look at the endpoint, HTTP method, parameters, and response.

Does the application return different messages depending on whether the email address exists?

For example: Email address not found. versus Password reset link sent.

That difference might allow username or email enumeration.

It isn't necessarily account takeover, but it can still expose information about registered users.

Step 2: Examine the reset link

Open the reset email sent to your own test account.

Look at the link.

Does it contain a token?

Is the link using HTTPS?

Does the token appear to change when you request a new reset?

These are useful observations, but appearances alone don't prove whether a token is cryptographically secure.

You also want to understand what the token actually authorizes.

Step 3: Capture the password change request

Open Alice's reset link and enter a new password.

Before completing the reset, capture the submission request in Caido.

Send a copy to Replay.

Now inspect the parameters.

For example: token=abc123&username=alice&new_password=TestPassword123

Ask yourself: Why is the username included?

Does the backend independently check that the token belongs to Alice?

What happens if the username is changed to another account that you own?

Use Bob, your second test account, to investigate this safely.

If Alice's reset token can modify Bob's password, you've found a serious flaw.

Do not perform this test against unrelated users' accounts.

Step 4: Check whether the token is actually required

In your lab, inspect what happens if the token is missing, empty, or altered.

Does the server reject the request?

Or does it process the password change anyway?

A particularly dangerous implementation is one that checks the token when displaying the reset form but forgets to validate it when the new password is submitted.

The server must verify the token at the point where the credential is changed.

Displaying a legitimate-looking form isn't proof that the final action is protected.

Step 5: Test token reuse and expiration

Complete a successful password reset.

Then attempt to use the same token again on your own test account.

A properly implemented single-use token should no longer authorize another password change.

Also check whether expired tokens are rejected.

Don't assume a token is invalid just because the webpage displays an error. Confirm that the backend refuses the actual password-change operation.

Step 6: Check what happens to existing sessions

Imagine you're logged in on your laptop and phone.

You reset your password.

What happens to those existing sessions?

Depending on the application's security requirements, it may need to revoke sessions automatically, require reauthentication, or give the user a clear option to invalidate other sessions.

For sensitive applications, session handling after password recovery deserves particular attention.

An account recovery process isn't complete simply because the password field was updated.

Login vs Password Reset: The actual comparison

Login

• Verifies the user using existing credentials
• Commonly uses passwords, passkeys, or MFA
• Requires protection against credential guessing
• Creates or updates an authenticated session
• A flaw may allow unauthorized access

Password Reset

• Establishes authority to replace a credential
• Commonly uses email links, recovery codes, or other recovery methods
• Requires protection against token guessing and recovery abuse
• Changes the credentials used to authenticate
• A flaw may allow unauthorized credential changes or account recovery

Neither workflow is inherently more secure.

A correctly implemented login can be secure.

A correctly implemented reset process can also be secure.

The risk comes from treating recovery as a minor feature rather than part of the application's authentication architecture.

And that mistake can be costly.

The part developers sometimes overlook

It's tempting to focus most authentication testing on the login form.

After all, that's where users enter their passwords.

But account security extends beyond /login.

Consider all the other features connected to identity:

• Password reset
• Email address changes
• MFA enrollment and recovery
• Backup code generation
• Session management
• Account recovery through customer support

These features don't necessarily authenticate users in the same way, but they can affect who controls an account.

For example, an email-change vulnerability might let someone redirect future password reset messages to an email address they control.

A poorly protected MFA reset feature might let someone disable a second factor.

And a broken password reset endpoint might allow credentials to be replaced without the required proof of ownership.

These aren't always separate problems.

Sometimes, one vulnerable workflow makes another vulnerable workflow far more dangerous.

That's why authentication testing shouldn't stop after you verify the login page.

So which one is the real authentication system?

Here's my answer.

Both are part of the larger account security system, but they serve different purposes.

Login verifies whether someone can access an account using an accepted authentication method.

Password recovery verifies whether someone has enough authority to replace a credential when the normal method isn't available.

One grants access.

The other can change what grants access.

And that makes password recovery extremely security-sensitive.

A banking application might have excellent login protections, but if its recovery flow allows someone to take over another account, those protections may not be enough.

On the other hand, a bank with carefully designed recovery checks can maintain strong security even when users forget passwords or lose their devices.

The vulnerability isn't the existence of a recovery option.

It's failing to protect it properly.

So the next time you're testing a web application, pay attention to the login page.

But don't stop there.

Click Forgot Password.

Follow the entire recovery process.

Inspect the requests.

See which values the server trusts.

Understand how it verifies ownership.

And ask yourself one question:

If I can't get through the front door, does the recovery process provide another way to take control of the account?

That's where authentication testing gets interesting.

Further reading

1. OWASP — Forgot Password Cheat Sheet
2. OWASP — Multifactor Authentication Cheat Sheet
3. PortSwigger — Password Reset Broken Logic Lab
4. OWASP — Authentication Cheat Sheet