Timing Attacks on Web Applications
Timing attacks infer secrets from how long an application takes to respond, rather than from what it returns. They are a class of side-channel attack: the app never intends to reveal the information, but its response time leaks it. On the web, tiny, measurable differences — does this username exist, did this comparison fail early — can be amplified across many requests into a real disclosure.
How do web timing attacks leak secrets?#
Two common patterns:
- User enumeration — if a login takes noticeably longer for a valid username (because it then hashes a password) than for an invalid one, an attacker can distinguish real accounts by timing.
- Non-constant-time comparison — a naive check of a token or hash returns as soon as it finds a mismatched byte. The response time reveals how many leading bytes matched, letting an attacker recover a secret one byte at a time.
Naive compare: returns on first difference
"aaaa" vs "abcd" → fails fast (1 byte matched)
"abcd" vs "abcz" → fails slower (3 bytes matched)
Timing reveals the matching prefixHow do you defend against them?#
| Defense | Protects |
|---|---|
| Constant-time comparison | Tokens, hashes, signatures |
| Uniform auth response time | Prevents user enumeration |
| Consistent error handling | No fast/slow branches on secrets |
| Added jitter (limited use) | Raises measurement cost |
The essential control is constant-time comparison for anything secret — most languages provide
a function (hmac.compare_digest, crypto.timingSafeEqual) that always takes the same time
regardless of where the values differ.
Timing attacks connect web security to cryptographic side channels and entropy. More at the Web Security hub.
Frequently asked questions#
What is a timing attack?
A timing attack is a side-channel attack that infers secret information from how long an operation takes. On the web, differences of even milliseconds — whether a username exists, or how far a password comparison got before failing — can leak data. The attacker measures response times across many requests to extract the secret.
What is constant-time comparison?
Constant-time comparison checks two values (like a token or password hash) in a way that always takes the same amount of time regardless of where they first differ. A naive comparison returns early on the first mismatched byte, leaking position information through timing. Security-sensitive comparisons must use constant-time functions.