HMAC-SHA1 Authentication

HMAC-SHA1 uses the SHA-1 hash function within the HMAC construction to produce a 160-bit (20-byte) authentication code. Notably, HMAC-SHA1 remains considered secure for authentication purposes even though SHA-1 itself has been broken for collision resistance. This distinction is important and often misunderstood.

Why HMAC-SHA1 is still secure:

HMAC's security depends on the pseudorandom function (PRF) property of the underlying hash, not its collision resistance. The known attacks against SHA-1 exploit collision resistance (finding two inputs with the same hash), but HMAC requires an attacker to forge a tag without knowing the secret key. No practical attack against HMAC-SHA1 has been demonstrated. The security proof for HMAC shows it remains secure as long as the compression function of the underlying hash is a PRF, which SHA-1's compression function still is.

Where HMAC-SHA1 is actively used:

HMAC-SHA1 is the default algorithm for TOTP (Time-based One-Time Password, RFC 6238) and HOTP (HMAC-based One-Time Password, RFC 4226), which power most two-factor authentication apps like Google Authenticator and Authy. OAuth 1.0 uses HMAC-SHA1 for request signing. Many legacy API authentication systems rely on HMAC-SHA1.

Migration considerations:

While HMAC-SHA1 remains theoretically secure, many organizations choose to migrate to HMAC-SHA256 for several practical reasons: compliance frameworks (PCI-DSS, FIPS 140-3) may require SHA-256; automated security scanners flag SHA-1 usage regardless of context; and migrating proactively avoids future urgency if a PRF-breaking attack on SHA-1 is ever discovered. The migration is usually straightforward since the HMAC interface is the same regardless of the underlying hash.

Implementation notes:

When implementing HMAC-SHA1, use your platform's standard crypto library. The output is 20 bytes, often truncated for OTP applications (TOTP uses dynamic truncation to extract a 6 or 8 digit code). For TOTP compatibility, you must use HMAC-SHA1 specifically, since authenticator apps expect it. However, RFC 6238 does define TOTP with SHA-256 and SHA-512 as alternatives if both parties support them.