SHA256 Generator With Key: HMAC-SHA256 Explained

Why concatenation fails

SHA-256 processes the message block by block and its final state is the digest. Given sha256(secret + message) and the message length, an attacker can resume from that state and compute a valid digest for message + anything without ever knowing the secret. This is the length-extension attack.

HMAC is built specifically to close that hole: it hashes twice with two derived keys, so the output cannot be extended.

Generating an HMAC

Every standard library has it, and the key is passed as a key rather than mixed into the message:

# shell
printf %s 'message' | openssl dgst -sha256 -hmac 'secret'

# PHP
hash_hmac('sha256', $message, $secret);

# Python
import hmac, hashlib
hmac.new(secret, message, hashlib.sha256).hexdigest()

# Node
crypto.createHmac('sha256', secret).update(message).digest('hex');

Verifying in constant time

Comparing signatures with == leaks timing information: the comparison stops at the first differing byte, and an attacker who can measure that reconstructs the signature byte by byte.

Use the constant-time comparison your language provides — hash_equals() in PHP, hmac.compare_digest() in Python, crypto.timingSafeEqual() in Node. This is the single most-missed step in webhook verification code.

Where you meet it

Webhook signatures from Stripe, GitHub and most SaaS platforms. AWS Signature v4 request signing. JWTs signed with HS256, which is exactly HMAC-SHA256 over the header and payload.

One caveat worth knowing: HMAC proves the sender held the shared secret, so both parties can produce valid signatures. When you need to prove a specific party signed something, you need asymmetric signatures instead.