Home / Knowledge hub / Timing attack
Knowledge hub
Timing attack
Learning a secret by measuring how long your application takes to answer.
What it means
A timing attack works out a secret from how long a system takes to respond. If a check stops at the first wrong character, a guess with a longer correct prefix takes slightly longer to reject. Measure enough replies and the secret emerges, one piece at a time.
The server never says anything wrong. It simply behaves differently depending on the secret, and the clock reveals the difference. The gaps are tiny, but repeated measurements average out network noise.
Why it matters
Anything compared in a hurry can leak: an API key, a webhook signature, a reset token, a password hash. If an outsider can recover one of those, they skip the guessing limits and walk past your sign-in.
Timing also tells people which accounts exist. A sign-in that answers faster for unknown emails confirms who your customers are, which feeds enumeration and credential stuffing. Both are quiet and leave little in the logs.
How it shows up
You meet the problem wherever secrets are compared with an ordinary equals operator, and in sign-in code that does extra work only when the user exists. Hash checks on a real account take longer than the early exit for a missing one.
The usual fix is a constant-time comparison function, such as hmac.compare_digest in Python or crypto.timingSafeEqual in Node. For sign-in, do the same work either way and return the same message. Check every place a token, signature or key is compared.
Questions people ask
Timing attack, answered
Can a timing attack really work over the internet?
Yes. Researchers have shown remote timing attacks across real networks by taking many measurements and filtering out noise.
The smaller the difference, the more requests it needs, so rate limits and monitoring raise the cost but do not remove the flaw.
How do we prevent timing attacks?
Compare secrets with a constant-time function, and make code paths take the same work whether or not a record exists.
Use library functions for this. Writing your own is easy to get subtly wrong.
Is a timing attack the same as a side-channel attack?
It is one kind. A side channel is any leak from the way a system works rather than from its intended output, such as power use, cache behaviour or response time.
Timing is the one most relevant to web applications.
Does a WAF or rate limit stop timing attacks?
Only partly. Limits slow the attacker and make the noise harder to cancel, but a determined one can spread requests out over time.
Fixing the comparison is the real answer.
How would a pentest find one?
By comparing response times for valid and invalid inputs, such as known and unknown usernames, over many repeated requests.
It only counts as a finding when the difference is large and stable enough to use, and the report should show those measurements.
Sources
Where this comes from
Related
Terms that sit next to this one
Enumeration
Working out what exists by asking repeatedly and watching the answers.
HMAC
A hash mixed with a secret key, proving a message is unchanged and from the key holder.
Credential stuffing
Trying passwords leaked elsewhere, because people reuse them.
Brute force
Trying passwords or codes over and over until one of them works.
Padding oracle
An error message that lets an attacker decrypt data one piece at a time.
Does your sign-in answer differently?
Differences in response time or message that reveal valid accounts or secret values are things we look for, and a finding is reported only when we measured it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.