Cryptography & Security ToolsUpdated: September 2026

HMAC Signature Generator & Webhook Verifier

Generate and verify Hash-based Message Authentication Codes (HMAC-SHA256, HMAC-SHA512) for webhooks and REST APIs using the W3C Web Cryptography API.

Research: LocalTooldeck Financial & Engineering Team

Audit: Verified for Mathematical Accuracy

100% Secure & Client-Side: Your secret API keys and webhook payloads never leave your browser.

Presets:

Hash Algorithm

Secret Key Format

Signature Output

Secret Authentication Key (Signing Secret)

Message Payload (Raw Request Body)

Generated HMAC Signature

Webhook Signature Verifier

Awaiting Comparison

The Cryptographic Architecture of HMAC and Message Authentication

In distributed computer networks, verifying that a message originated from an authentic party and was not altered in transit is a paramount requirement. While public-key asymmetric digital signatures (such as RSA or ECDSA) provide non-repudiation, their computational overhead is significant. For high-velocity APIs, microservices, and webhooks, Hash-based Message Authentication Codes (HMAC) provide symmetric authentication with exceptional speed.

Formally standardized by the Internet Engineering Task Force (IETF) in February 1997 under RFC 2104 and reaffirmed in NIST FIPS PUB 198-1, HMAC combines a shared secret key with an underlying cryptographic hash function ($H$).

The Mathematical Formulation of RFC 2104

HMAC is mathematically defined as:

HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))

Where:

$K'$: The secret key adjusted to the block size ($B$) of the hash function (64 bytes for SHA-256). If $K$ is longer than $B$, it is pre-hashed $K' = H(K)$. If shorter, it is right-padded with zero bytes.
$ipad$: Inner padding constant, consisting of the byte 0x36 repeated $B$ times.
$opad$: Outer padding constant, consisting of the byte 0x5C repeated $B$ times.
$\oplus$: Bitwise exclusive-OR (XOR) operation.
$\parallel$: Byte concatenation.

Why Naive Secret Prefixing (Hash(Key + Message)) Fails Catastrophically

Early software developers frequently attempted to create custom authentication codes using the naive formulation MAC = Hash(Secret || Message). This design is fatally flawed against Length Extension Attacks when used with Merkle-Damgård hash algorithms:

Because SHA-256 processes messages in fixed 512-bit blocks, the output hash represents the internal state of the compression function after processing the final block. An attacker who intercepts a valid message and its hash can initialize the hash engine with that state, append arbitrary malicious data, and compute the valid signature for the combined payload without ever discovering the secret key. HMAC's nested two-pass structure completely eliminates length extension vulnerabilities.

Industry Standard Webhook Implementations

Provider	Signature Header	Algorithm	Replay Protection Mechanism
Stripe	Stripe-Signature	HMAC-SHA256 (Hex)	Prepends Unix timestamp `t=...` to payload
GitHub	X-Hub-Signature-256	HMAC-SHA256 (Hex with sha256= prefix)	Idempotency GUID (X-GitHub-Delivery)
AWS SigV4	Authorization: AWS4-HMAC-SHA256	HMAC-SHA256 (Derived Key Cascade)	x-amz-date ISO 8601 timestamp + 15 min window
Twilio	X-Twilio-Signature	HMAC-SHA1 (Base64)	Signed URL + POST parameter concatenation

Constant-Time String Comparison: Mitigating Side-Channel Timing Attacks

When an API server receives a webhook and verifies the signature, using standard comparison operators (like if (receivedSig == computedSig)) introduces a side-channel timing attack. Standard comparison routines return false immediately when the first non-matching byte is evaluated.

An attacker measuring sub-microsecond latency variations over millions of requests can deduce the signature byte-by-byte. In secure production services, verification must always execute in constant time, evaluating every byte regardless of early mismatches.

Frequently Asked Questions (US Standards)

Why is HMAC required instead of simple concatenated hashing like Hash(Secret + Message)?

Concatenating a secret key with a message using Merkle-Damgård hash algorithms (like MD5, SHA-1, and SHA-256) is vulnerable to Length Extension Attacks. An attacker knowing the hash of a message can append malicious data and compute the valid hash of the extended message without knowing the secret key. HMAC (RFC 2104) prevents this through a nested two-pass hashing construction.

How does the inner and outer padding (ipad and opad) work in HMAC?

HMAC computes HMAC(K, m) = H((K_prime XOR opad) || H((K_prime XOR ipad) || m)). The secret key K is first hashed or padded to the block size (64 bytes for SHA-256). It is then XORed with the inner pad constant (0x36 repeated) and concatenated with the message to compute the inner hash. That inner hash is then concatenated with the outer pad constant (0x5c repeated) XORed key and hashed again.

How do webhooks like Stripe and GitHub prevent replay attacks using HMAC?

Modern webhook providers bundle a Unix timestamp into the signature header (e.g. Stripe t=1719582000,v1=...). The HMAC signature is computed over the timestamp concatenated with the raw payload (e.g. 1719582000.{"event":"payment_succeeded"}). The receiving server verifies both the HMAC signature and confirms that the timestamp is within a 5-minute tolerance window, preventing replay attacks.

What are timing attacks in HMAC verification and how are they mitigated?

Standard string equality comparisons (like == or ===) terminate early upon encountering the first non-matching byte, causing response latency to correlate with the number of correct prefix bytes. Attackers can measure microsecond differences to deduce signatures. Verification must always utilize a constant-time comparison algorithm (e.g. crypto.timingSafeEqual() in Node.js or XOR-accumulated loops in browsers).