HMAC SHA-256 Generator
HMAC
8b...
How it works
HMAC-SHA-256 (Hash-based Message Authentication Code using SHA-256) combines a secret key with a message to produce an authentication tag. Unlike a plain hash, an HMAC can only be verified by someone who knows the secret key — making it suitable for API authentication, webhook verification, and JWT signing.
**How HMAC works** HMAC(K, M) = SHA-256((K' ⊕ opad) || SHA-256((K' ⊕ ipad) || M)) — where K' is the key padded/hashed to the block size, opad and ipad are fixed constants, and || is concatenation. The nested structure prevents length-extension attacks that affect plain SHA-256. This construction is proven secure as long as the underlying hash function is collision-resistant.
**Real-world uses** Webhook signatures: GitHub, Stripe, and Shopify sign webhook payloads with HMAC-SHA-256 and include the tag in a request header. The receiver recomputes the HMAC with their secret and compares — rejecting any request that does not match. JWT HS256: the header and payload are HMAC-signed by the server; clients cannot forge tokens without the server's secret. API authentication: AWS Signature Version 4 uses HMAC-SHA-256 in a chain of derived keys (date, region, service, request).
**Comparing HMACs safely** Always use constant-time comparison (crypto.timingSafeEqual in Node.js) when verifying an HMAC. Byte-by-byte comparison short-circuits on the first mismatch, enabling timing attacks that can recover the expected tag one byte at a time.
Frequently Asked Questions
- SHA-256 is vulnerable to length-extension attacks: given SHA-256(message), an attacker can compute SHA-256(message || padding || extension) without knowing the message. This is exploited to forge MAC values. HMAC avoids this by nesting: HMAC = SHA-256(outerKey || SHA-256(innerKey || message)). The outer SHA-256 wraps the inner result, making length extension impossible — the attacker would need to forge the inner hash first.
- When you configure a webhook endpoint, you provide a secret. When GitHub/Stripe delivers a webhook, they compute HMAC-SHA-256(secret, request_body) and include the result in the X-Hub-Signature-256 or Stripe-Signature header. Your server recomputes the HMAC using the same secret and compares — if they match, the request is authentic. Always use constant-time comparison (e.g., crypto.timingSafeEqual in Node.js) to prevent timing attacks.
- JWT HS256 (JSON Web Token, HMAC-SHA-256) signs the header.payload string with a shared secret using HMAC-SHA-256. The resulting token is header.payload.signature where the signature prevents tampering. HS256 is symmetric — both the issuer and verifier must know the same secret. For public APIs where the verifier should not know the signing secret, use RS256 (RSA asymmetric signing) instead.
- No — HMAC is not suitable for password storage. HMAC-SHA-256 is fast (millions of operations/second on a GPU), making brute-force attacks trivial. For password hashing, use bcrypt, scrypt, or Argon2id — designed to be slow and memory-intensive, making GPU attacks expensive. HMAC is appropriate for message authentication (webhooks, APIs) and key derivation within established protocols, not for storing secrets.