Timing Attacks in Password Reset: How Attackers Enumerate Accounts

When developers think about password reset security, they usually focus on protecting reset tokens, enforcing expiration times, and preventing brute-force attacks. However, there's another class of vulnerability that often goes unnoticed: timing attacks.

A timing attack doesn't steal passwords or bypass authentication. Instead, it allows an attacker to determine whether an account exists simply by measuring how long a server takes to respond.

What Is a Timing Attack?

A timing attack exploits differences in the time required to execute different code paths.

If two requests receive the same HTTP response but one consistently takes longer than the other, an attacker can infer what happened internally.

In password reset functionality, this often becomes an account enumeration attack.

The attacker is trying to answer a single question:

Does this email belong to a real account?

A Typical Password Reset Flow

A user submits an email address to request a password reset.

Notice that both responses appear identical to the user. A secure application should never reveal whether the email exists. However, response timing may still reveal the answer.

Where the Timing Difference Comes From

For an existing account, the application typically performs additional work:

Find the user
Start a database transaction
Invalidate previous reset tokens
Generate a new secure token
Save the token
Commit the transaction

For a non-existent account, many implementations simply return immediately after the lookup.

Although both responses contain the same message, the server performs vastly different amounts of work.

How an Attacker Exploits It

An attacker sends many password reset requests using different email addresses.

alice@example.com
bob@example.com
charlie@example.com
finance@example.com
ceo@example.com

alice@example.com
bob@example.com
charlie@example.com
finance@example.com
ceo@example.com

Instead of examining the response body, they measure response time.

alice@example.com      118 ms
bob@example.com         12 ms
charlie@example.com    121 ms
unknown@example.com      9 ms

alice@example.com      118 ms
bob@example.com         12 ms
charlie@example.com    121 ms
unknown@example.com      9 ms

After repeating these requests hundreds of times, statistical averaging removes most network noise.

The attacker can now classify addresses as either:

likely existing
likely non-existing

without ever accessing the database.

Why Repeated Measurements Work

Internet latency is unpredictable. One request might take longer simply because of network congestion. However, attackers don't rely on a single measurement.

They collect many samples.

Over many requests, the execution time of the application becomes much more visible than random network fluctuations.

Why This Matters

At first glance, discovering whether an account exists may not seem dangerous.

However, attackers rarely stop there. A verified list of accounts can significantly improve the effectiveness of later attacks.

For example:

targeted phishing campaigns
password spraying
credential stuffing
social engineering
attacks against privileged users

Instead of attacking millions of random email addresses, attackers can focus exclusively on valid accounts.

What the Attacker Cannot Obtain

A timing attack does not reveal:

passwords
password hashes
reset tokens
session cookies
JWTs
encryption keys

It only leaks one piece of information:

Does this account exist?

Although that may sound minor, information disclosure is still a security vulnerability.

The Root Cause

The vulnerability exists because different code paths perform different amounts of work.

The greater the difference in execution time, the easier it becomes to distinguish between the two outcomes.

Mitigation Strategies

The primary objective is to ensure both execution paths consume approximately the same amount of time.

Instead of returning immediately when no account exists, applications can perform equivalent work before responding.

For example:

Both responses should:

return the same HTTP status
return the same response body
perform a similar amount of computation
complete in approximately the same time

Many mature authentication systems also introduce controlled timing equalization so that neither path becomes distinguishable.

Severity

Password reset timing attacks are generally considered Low to Medium severity.

On their own, they do not compromise accounts.

However, they expose information that attackers can combine with phishing, credential stuffing, or password spraying to increase the likelihood of successful attacks.

For organizations protecting sensitive users such as banks, healthcare providers, government systems, and enterprise identity platforms even small information leaks can have meaningful security implications.

Final Thoughts

Authentication endpoints should not only return identical responses they should also behave similarly from an attacker's perspective.

A password reset request that takes 120 ms for one email address and 10 ms for another silently reveals information that the application intended to keep secret.

By equalizing both the response content and the amount of work performed, developers can eliminate this subtle but effective account enumeration technique, making authentication systems significantly more resilient against reconnaissance attacks.

Contents