HMAC vs hash: why message authentication needs a key

3 min read
HMACCryptographyAuthentication

HMAC (Hash-based Message Authentication Code) is often described as “hashing with a key”, but the reason that small change makes it authentication rather than just integrity is worth unpacking.

Hashing alone is not authentication

A hash function like SHA-256 produces a fixed-length fingerprint of a message. Equal messages produce equal hashes, which is great for tamper detection:

sha256("hello") = 2cf24dba...
sha256("hellp") = 4e07408...

But the hash alone cannot prove who produced the message. An attacker can craft any message, compute its hash, and ship the pair:

forged "malicious command" + its sha256

A receiver that only checks “hash matches” will accept it. Nothing distinguishes the legitimate sender from anyone else.

HMAC: only people with the key can produce it

HMAC takes a secret key shared between sender and receiver and folds it into the hash:

HMAC(key, message) = a hash that requires the key to produce

Without the key, an attacker cannot generate a matching HMAC. The receiver recomputes the HMAC with its own copy of the key — equality means “the holder of the key produced this”.

HMAC structure (simplified)

For HMAC-SHA256:

HMAC(K, m) = H( (K ⊕ opad) || H( (K ⊕ ipad) || m ) )
  • H is the hash (SHA-256, etc.)
  • K is the key
  • opad is the byte 0x5c repeated, ipad is 0x36 repeated
  • || is concatenation

The two-stage hash defends against the length-extension attack that plain H(K || m) is vulnerable to.

Why naive H(key || message) fails

SHA-256 is vulnerable to length extension: knowing H(K || m) lets an attacker compute H(K || m || padding || extra) without knowing K. That breaks authentication if you simply prepend the key to the message before hashing.

HMAC’s ipad/opad construction structurally avoids this.

Where HMAC shows up

1. JWT HS256 signatures

JWT with alg: HS256 signs claims with HMAC-SHA256. The server holds the secret and can verify that a token is unaltered.

2. Webhook signing

GitHub, Stripe, Slack, and others sign webhook payloads with HMAC and put the result in a header:

X-Hub-Signature-256: sha256=<HMAC>

The receiver recomputes locally to confirm the request is from the legitimate sender.

3. API request signing

AWS Signature v4 and similar schemes use HMAC over canonicalized request data, with access-key/secret-key pairs.

4. Session token integrity

Sessions stored client-side (signed cookies, JWTs) carry an HMAC so tampering is detectable.

Key management essentials

HMAC’s security rests on the key:

  • Use ≥ 256 bits of randomness for HMAC-SHA256 (32 random bytes minimum).
  • Keep it secret — env vars, secret managers, never source-controlled.
  • Rotate — support multiple active keys to enable rolling rotation.
  • Compare in constant time — use crypto.timingSafeEqual (Node) or equivalent to defeat timing attacks.

How HMAC differs from public-key signatures

HMAC is symmetric (same key on both ends). Public-key signatures (RSA, ECDSA) are asymmetric (private key signs, public key verifies).

  • HMAC: faster; key distribution is the constraint.
  • Public-key: slower; easy distribution; provides non-repudiation.

For server-to-server webhooks where keys can be pre-shared, HMAC fits. For tokens that need to be verifiable by many parties without a shared secret, public-key signatures (RS256, ES256) win.

Summary

  • A bare hash proves integrity, not origin.
  • HMAC mixes a secret key into the hash, gaining authentication.
  • Plain H(key || message) is vulnerable to length extension; HMAC’s two-stage structure prevents it.
  • Used in JWT, webhooks, API signing, session tokens.

To compute HMAC values for testing, the HMAC generator on this site supports SHA-256, SHA-1, and MD5 with a configurable key.