HMAC

Cosa aggiunge HMAC sopra un hash

Un hash crittografico semplice crea un’impronta dei dati: chiunque può ricalcolare SHA-256(message) e confrontare. Un HMAC (Hash-based Message Authentication Code) mescola una chiave segreta con il messaggio prima dell’hash, così solo le parti che conoscono la chiave possono produrre o verificare il tag. Il risultato è un digest a lunghezza fissa—spesso in hex—che autentica integrità e origine nel modello di segreto condiviso.

HMAC è ampiamente usato per firme di richieste API, verifica di webhook e cookie firmati. Non cifra il messaggio; se serve riservatezza, usate un cifrario o TLS. Non sostituisce nemmeno le firme a chiave pubblica quando le parti non devono condividere un unico segreto.

Calcolate un tag moderno con HMAC SHA-256 usando un messaggio di esempio e un segreto solo di test.

Subtool di questa famiglia

L’hub offre la stessa costruzione HMAC su tre funzioni hash sottostanti:

• HMAC SHA-256 — default preferito per nuove integrazioni; comune in firme stile AWS, JWT HS256 e molti schemi webhook.
• HMAC SHA-1 — ancora presente in API più vecchie; migrate quando controllate entrambe le estremità.
• HMAC MD5 — solo legacy; utile per capire MAC stile checksum antichi, non per nuovi progetti di sicurezza.

Scegliete il subtool che corrisponde al nome dell’algoritmo nel protocollo che implementate. Un HMAC SHA-256 non verificherà contro un HMAC MD5 dello stesso messaggio e chiave.

Come è costruito HMAC (intuizione)

RFC 2104 definisce HMAC a grandi linee come hashing di una combinazione di chiave e messaggio con blocchi di chiave paddati interni ed esterni. Proprietà di engineering importanti:

• La chiave resta segreta; il solo digest non dovrebbe rivelarla.
• Cambiare qualsiasi bit del messaggio (o della chiave) produce un tag diverso con probabilità schiacciante.
• La verifica è ricalcola-e-confronta—idealmente in tempo costante nei percorsi sensibili alla sicurezza.

Non dovete implementare il padding a mano quando esiste una funzione di libreria standard HMAC(hashAlg, key, message)—e in produzione dovreste preferire quelle librerie.

Chiavi, messaggi e encoding

Qualità della chiave. Usate chiavi lunghe e casuali da un CSPRNG. Le passphrase umane sono più deboli se non passano da un KDF adeguato. Non usate la stessa chiave per due protocolli diversi senza domain separation.

Byte del messaggio. HMAC autentica byte esatti. Un JSON con diverso ordine delle chiavi o spazi produce un tag diverso anche se la semantica coincide. Canonicalizzate i dati strutturati prima di firmare se esistono più produttori.

Encoding di output. Le librerie possono restituire byte grezzi, hex o Base64. Due sistemi che confrontano i tag devono accordarsi su encoding e maiuscole/minuscole dell’hex. JWT e molti schemi HTTP usano Base64URL anziché hex—seguite la specifica.

Flussi tipici

Verifica webhook. Un provider invia un payload più un header X-Signature. Il vostro server ricalcola HMAC sul corpo grezzo con il segreto condiviso e confronta.

Firma di richieste API. Una stringa canonica (metodo, path, timestamp, hash del body) è coperta da HMAC così gli intermediari non possono alterare la richiesta senza essere notati.

Imparare JWT HS256. I JSON Web Token firmati con HS256 sono HMAC-SHA-256 su base64url(header) + "." + base64url(payload). Vedete anche l’hub JWT per i flussi encode/decode/verify.

Scegliere MD5, SHA-1 o SHA-256

Gli attacchi di collisione contro MD5 e SHA-1 contano soprattutto per hashing non keyed e abuso di certificati. HMAC-MD5 e HMAC-SHA-1 sono più forti di MD5/SHA-1 nudi per l’autenticità in alcuni modelli di minaccia, ma la guida moderna orienta ancora i nuovi progetti a HMAC-SHA-256 (o più forte) per agilità algoritmica e semplicità di policy. Se un vendor offre solo HMAC-MD5, trattatelo come vincolo di compatibilità e isolate quell’integrazione.

Errori comuni

• Pubblicare il segreto in app mobili o JavaScript front-end e aspettarsi che HMAC dimostri qualcosa al server.
• Hashare con SHA-256 dimenticando il passo della chiave HMAC (o il contrario).
• Firmare un body parsato e ri-serializzato invece dei byte grezzi della richiesta.
• Usare uguaglianza di stringhe non sicura nel timing (=== in alcuni contesti) per confrontare i tag in codice high-assurance.
• Ruotare le chiavi senza una finestra di dual-verify, causando improvvisi fallimenti di verifica.

Limiti e ambiente

Questi strumenti browser aiutano a generare e confrontare digest mentre si impara o si fa debug. Non sono un sistema di key management. Tenete i veri segreti di produzione in store lato server; usate chiavi usa-e-getta per le demo.

Sintesi

HMAC trasforma una funzione hash in un autenticatore a chiave. Questo hub offre HMAC-MD5, HMAC-SHA-1 e HMAC-SHA-256 così potete soddisfare i requisiti di protocollo e vedere come i digest cambiano con messaggio o chiave. Preferite SHA-256 per lavoro nuovo, canonicalizzate i byte prima di firmare e ricordate che HMAC autentica—non cifra.