You are building a webhook receiver. The docs say "verify the signature header using HMAC-SHA256 and our shared secret." What does that sentence actually mean, and how do you avoid messing up the comparison? Feed a message, key, and hash algorithm (SHA-256, 384, or 512) into this tool, get back a tag, compare that tag to the signature header. If it matches, the payload has not been tampered with and it came from someone who knows the shared key.
An HMAC is just a hash with a lock on it. A plain SHA-256 is verifiable by anyone. An HMAC-SHA256 is verifiable only by parties who know the secret key. If you are signing JWTs, API payloads (Stripe, PayPal, GitHub webhooks all do this), or session cookies, you are computing HMACs -- whether you realized it or not.
The gotcha silently broken in more code than you would expect: the timing attack.
When verifying an HMAC, most code reaches for ===. A standard string comparison bails out at the first wrong byte. That means a tag where the first byte matches returns slightly faster than one where byte 7 mismatches. Measure that timing delta a thousand times and you can extract the correct tag byte-by-byte, left to right. JWT libraries have shipped real-world exploits for this. Verification must use a constant-time comparison: walk both strings in full, accumulate XOR differences, return the result at the end. This tool does.
Inside HMAC itself there is a deliberate double-hash:
HMAC(K, m) = H( (K' ^ opad) || H( (K' ^ ipad) || m ) )
That construction gives HMAC one property a naive H(key || message) does not have: immunity to length-extension attacks. A vanilla SHA-256 lets an attacker append data to message and compute a new valid hash without knowing the key. The nested hashing destroys that capability. Never invent your own "HMAC-ish" scheme by concatenating key and message; use the standard.
Practical notes for wiring this into real systems:
-
Key length should be at least the hash output size -- 32 bytes for SHA-256, 64 for SHA-512. HMAC internally hashes the key to the block size, so over-length keys do not buy anything; under-length keys are only slightly weaker.
-
Output encoding matters. Webhooks typically send HMACs as lowercase hex (
X-Hub-Signature-256: sha256=abc123...). AWS SIGv4 also uses hex. Some APIs use base64. The tool emits in both; match what your verifier expects. -
Verification mode does the HMAC computation and runs constant-time comparison against a paste-in tag. Cannot do the comparison for you at 3 AM, but it saves the tag you expect so you can diff.
-
Key handling: whatever you do, do not hard-code a secret key next to the HMAC call. HMAC security is entirely key secrecy. If the key leaks, anyone can forge valid tags.
HMACs do not encrypt. They do not compress. They do exactly one thing well: prove that a message still says what the keyholder originally said.