Timing attacks and constant-time comparison of secrets

What it is

A timing side channel exists when how long an operation takes depends on secret data. The classic case is comparing a submitted value with a stored secret using ordinary equality: the comparison returns as soon as one byte differs, so a guess with the correct first byte takes slightly longer than a guess with a wrong one. Repeated measurements average out noise and let an attacker recover the value byte by byte. Standard libraries provide comparisons whose duration does not depend on the contents: Python's hmac.compare_digest uses "an approach designed to prevent timing analysis by avoiding content-based short circuiting behaviour"; Node's crypto.timingSafeEqual compares the underlying bytes with a constant-time algorithm and is documented as suitable for HMAC digests, authentication cookies and capability URLs; Go's subtle.ConstantTimeCompare takes time that depends on the lengths and is independent of the contents.

Why it matters

Everything a server compares against a secret is affected: webhook signatures, API keys, password-reset tokens, session identifiers, CSRF tokens, HMAC tags on signed cookies. Whether the leak is exploitable across a noisy network is a question of sample count, not of principle; the constant-time function is cheap and removes the question.

How to apply

• Compare every secret-bearing value with the platform's constant-time function, never with == or string equality, and do not look the record up by the plaintext token (WHERE token = ?), since a database comparison is not a constant-time compare; look up by a non-secret id or by a hash of the token, then compare in constant time.
• Mind the length rule. All three functions treat differing lengths specially: Python's note says a length mismatch can reveal the lengths but not the values, Node throws, Go returns 0 immediately. Compare fixed-length digests, or hashes of the inputs, so that lengths always match.
• Keep the whole path constant, not only the compare: when a username does not exist, still verify the password against a dummy hash so that "unknown user" and "wrong password" take the same time.
• Store server-side bearer tokens as hashes and compare the hashes; a leaked table then does not contain usable tokens either.

Pitfalls

A constant-time compare does not repair a variable-time step before it, such as branching on the secret's prefix or a decoder that rejects early; Node's documentation states that using timingSafeEqual does not guarantee that the surrounding code is timing-safe. Rate limiting reduces the attacker's samples but is a second line, not a substitute. A hand-written comparison loop may be transformed by a compiler or runtime in ways that reintroduce data-dependent timing; use the library function.