OSVDB-97562: OAuth Protocol HMAC Timing Disclosure Weakness

OSVDB ID: 97562 · Class: Cryptographic weakness / timing side-channel · Affected: OAuth protocol implementations performing HMAC signature verification with non-constant-time comparison.

Summary

OSVDB-97562 documents a timing disclosure weakness in the way certain OAuth implementations verify request signatures. When the server compares the client-supplied HMAC against the expected value byte-by-byte and returns as soon as a mismatch is found, the time taken to reject a forged signature leaks how many leading bytes were correct.

Technical detail

OAuth 1.0 request signing relies on an HMAC (typically HMAC-SHA1) computed over the normalized request. The server recomputes the HMAC and compares it to the value presented by the client. A naive comparison — for example a standard string/array equality that short-circuits on the first differing byte — takes measurably longer when more leading bytes match.

By issuing a large number of requests and measuring response latency, an attacker can perform a classic byte-at-a-time timing attack: fix all known-good leading bytes, vary the next byte across its 256 possible values, and keep the value that is rejected slowest. Repeating this recovers the full valid signature for a chosen request without ever knowing the shared secret.

Impact

Successful exploitation lets an attacker forge a valid signature for a specific request, defeating the integrity guarantee that the HMAC is meant to provide. The weakness is subtle because the cryptography itself is sound — the flaw is entirely in the comparison step.

Mitigation

• Use a constant-time comparison for all secret/MAC checks (e.g. hmac.compare_digest in Python, crypto.timingSafeEqual in Node.js, subtle.ConstantTimeCompare in Go).
• Compare fixed-length digests, not variable-length user input, and avoid early-return equality on secret material.
• Where feasible, add server-side rate limiting and jitter as defence-in-depth, though constant-time comparison is the actual fix.

References & archive note

This entry preserves the record originally catalogued as OSVDB-97562 in the Open Source Vulnerability Database. OSVDB shut down in 2016; Secably maintains a topical archive of referenced OSVDB identifiers so that long-standing academic and standards citations continue to resolve to accurate vulnerability information.