What is HMAC?
HMAC (Hash-based Message Authentication Code) is a cryptographic mechanism that combines a secret key with a hash function to produce a message authentication code. Unlike a plain hash, HMAC guarantees both data integrity and authenticity— only someone who possesses the secret key can generate (or verify) a valid HMAC for a given message.
HMAC was defined in RFC 2104 and is widely used across the internet for API authentication, webhook verification, and secure token generation. It is resistant to length-extension attacks that affect plain hash constructions, making it the recommended approach for keyed hashing.
How HMAC Works
HMAC uses a two-pass hashing process. Given a secret key K and a message M:
- The key is padded or hashed to match the block size of the hash function.
- An inner hash is computed:
H((K ⊕ ipad) || M) - An outer hash wraps the result:
H((K ⊕ opad) || inner_hash)
This double-hashing construction ensures that even if an attacker knows the hash function's internal state after processing the message, they cannot forge a valid HMAC without the secret key.
Common Use Cases for HMAC
API authentication
Services like AWS, Stripe, and GitHub use HMAC signatures to authenticate API requests. The client signs each request with a shared secret, and the server verifies the signature.
Webhook verification
When receiving webhooks from third-party services, HMAC lets you verify that the payload was genuinely sent by the expected service and hasn't been tampered with.
JSON Web Tokens (JWT)
JWTs signed with the HS256, HS384, or HS512 algorithms use HMAC-SHA to ensure the token's claims haven't been modified since issuance.
Message integrity
HMAC can protect data in transit or at rest, allowing recipients to verify that the data hasn't been altered and originated from a trusted source.
Session tokens & cookies
Web frameworks sign session cookies with HMAC so that clients cannot tamper with session data without invalidating the signature.
TOTP / 2FA codes
Time-based one-time passwords (TOTP) used in two-factor authentication are generated using HMAC-SHA1 or HMAC-SHA256 over a timestamp and shared secret.
HMAC vs Plain Hash
| Feature | Plain Hash | HMAC |
|---|---|---|
| Requires secret key | No | Yes |
| Data integrity | Yes | Yes |
| Authentication | No | Yes |
| Length-extension resistant | No (SHA-256, SHA-512) | Yes |
| Use case | Checksums, fingerprints | API auth, webhook signing |
HMAC Algorithm Comparison
| Algorithm | Output Length | Security | Common Usage |
|---|---|---|---|
| HMAC-SHA-256 | 256 bits (64 hex) | Strong — industry standard | AWS Signature V4, Stripe, most APIs |
| HMAC-SHA-384 | 384 bits (96 hex) | Strong — higher margin | TLS 1.3, government systems |
| HMAC-SHA-512 | 512 bits (128 hex) | Strong — maximum security | High-security applications, JWT HS512 |
Frequently Asked Questions
Yes. All HMAC computation is performed entirely in your browser using the Web Crypto API. Your message and secret key never leave your device — nothing is uploaded to any server.
A regular hash (like SHA-256) only ensures data integrity — anyone can compute it. HMAC combines a secret key with the hash, providing both integrity and authentication. Only someone with the secret key can produce a valid HMAC.
HMAC-SHA-256 is the most widely used and recommended for most applications. It offers strong security and is the default for AWS Signature V4, Stripe webhooks, and many other services. Use HMAC-SHA-512 if you need maximum security or are working with 64-bit systems where it may be faster.
No. HMAC is based on one-way hash functions and is computationally infeasible to reverse. An attacker cannot recover the secret key from an HMAC output, even if they know the message and the hash algorithm used.
In API authentication, the client creates an HMAC signature by hashing the request details (method, URL, headers, body) with a shared secret key. The server independently computes the same HMAC and compares it to the one sent by the client. If they match, the request is authentic.
JSON Web Tokens (JWT) can be signed using HMAC algorithms: HS256 (HMAC-SHA-256), HS384 (HMAC-SHA-384), and HS512 (HMAC-SHA-512). The HMAC signature ensures that the token's payload (claims) haven't been modified. Both the issuer and verifier share the same secret key.
Yes. HMAC-SHA-256 is considered secure against all known cryptographic attacks and is widely deployed in production systems worldwide. Major cloud providers (AWS, Google Cloud, Azure) and payment processors (Stripe, PayPal) rely on HMAC-SHA-256 for their security infrastructure.
Yes. The secret key should be at least as long as the hash output (32 bytes for SHA-256, 64 bytes for SHA-512) for optimal security. Keys shorter than the hash output reduce the effective security level. Keys longer than the block size are first hashed down, so excessively long keys don't add extra security.
A length-extension attack allows an attacker who knows H(message) to compute H(message || padding || extra) without knowing the original message. This affects plain SHA-256 and SHA-512 hashes. HMAC's double-hashing construction (inner hash + outer hash) completely prevents this attack.
HMAC alone is not recommended for password hashing because it's designed to be fast. For passwords, use dedicated slow-hashing algorithms like bcrypt, scrypt, or Argon2 that include built-in salting and configurable work factors to resist brute-force attacks.