HMAC

Ce qu’HMAC ajoute par-dessus un hash

Un hash cryptographique simple empreinte des données : n’importe qui peut recalculer SHA-256(message) et comparer. Un HMAC (Hash-based Message Authentication Code) mélange une clé secrète au message avant le hachage, de sorte que seules les parties qui connaissent la clé peuvent produire ou vérifier l’étiquette. Le résultat est un digest de longueur fixe—souvent en hex—qui authentifie intégrité et origine sous le modèle de secret partagé.

HMAC est largement utilisé pour les signatures de requêtes API, la vérification de webhooks et les cookies signés. Il ne chiffre pas le message ; pour la confidentialité, utilisez un chiffrement ou TLS. Il ne remplace pas non plus les signatures à clé publique quand les parties ne doivent pas partager un seul secret.

Calculez une étiquette moderne avec HMAC SHA-256 à partir d’un message d’exemple et d’un secret réservé aux tests.

Sous-outils de cette famille

Le hub propose la même construction HMAC sur trois fonctions de hachage sous-jacentes :

• HMAC SHA-256 — défaut préféré pour les nouvelles intégrations ; courant dans les signatures style AWS, JWT HS256 et de nombreux schémas de webhook.
• HMAC SHA-1 — encore rencontré dans d’anciennes API ; migrez quand vous contrôlez les deux extrémités.
• HMAC MD5 — legacy uniquement ; utile pour comprendre d’anciens MAC style checksum, pas pour de nouveaux designs de sécurité.

Choisissez le sous-outil qui correspond au nom d’algorithme dans le protocole implémenté. Un HMAC SHA-256 ne vérifiera pas contre un HMAC MD5 du même message et de la même clé.

Comment HMAC est construit (intuition)

RFC 2104 définit HMAC à peu près comme le hachage d’une combinaison clé/message avec blocs de clé paddés internes et externes. Propriétés d’ingénierie importantes :

• La clé reste secrète ; le digest seul ne doit pas la révéler.
• Changer n’importe quel bit du message (ou de la clé) donne une autre étiquette avec une probabilité écrasante.
• La vérification est recalculer-et-comparer—idéalement en temps constant pour les chemins sensibles à la sécurité.

Vous n’avez pas besoin d’implémenter le padding à la main quand une fonction de bibliothèque standard HMAC(hashAlg, key, message) existe—et vous devriez préférer ces bibliothèques en production.

Clés, messages et encodages

Qualité de la clé. Utilisez de longues clés aléatoires d’un CSPRNG. Les passphrases humaines sont plus faibles sauf passage par un KDF adéquat. N’utilisez pas la même clé pour deux protocoles différents sans séparation de domaine.

Octets du message. HMAC authentifie des octets exacts. Un JSON avec un autre ordre de clés ou des espaces produit une autre étiquette même si la sémantique correspond. Canonicalisez les données structurées avant de signer s’il existe plusieurs producteurs.

Encodage de sortie. Les bibliothèques peuvent renvoyer des octets bruts, de l’hex ou du Base64. Deux systèmes qui comparent des étiquettes doivent s’accorder sur l’encodage et la casse de l’hex. JWT et beaucoup de schémas HTTP utilisent Base64URL plutôt que hex—suivez la spécification.

Flux typiques

Vérification de webhooks. Un fournisseur envoie une charge plus un en-tête X-Signature. Votre serveur recalcule HMAC sur le corps brut avec le secret partagé et compare.

Signature de requêtes API. Une chaîne canonique (méthode, chemin, horodatage, hash du corps) est couverte par HMAC pour que des intermédiaires ne puissent pas altérer la requête sans être remarqués.

Apprendre JWT HS256. Les JSON Web Tokens signés avec HS256 sont HMAC-SHA-256 sur base64url(header) + "." + base64url(payload). Voir aussi le hub JWT pour les flux encode/decode/verify.

Choisir MD5, SHA-1 ou SHA-256

Les attaques par collision contre MD5 et SHA-1 comptent surtout pour le hachage non clé et le mauvais usage de certificats. HMAC-MD5 et HMAC-SHA-1 sont plus forts que MD5/SHA-1 nus pour l’authenticité dans certains modèles de menace, mais les conseils modernes orientent encore les nouveaux designs vers HMAC-SHA-256 (ou plus fort) pour l’agilité d’algorithme et la simplicité de politique. Si un fournisseur n’offre que HMAC-MD5, traitez-le comme contrainte de compatibilité et isolez cette intégration.

Erreurs courantes

• Publier le secret dans des apps mobiles ou du JavaScript front-end et attendre qu’HMAC prouve quelque chose au serveur.
• Hacher avec SHA-256 mais oublier l’étape de clé HMAC (ou l’inverse).
• Signer un corps parsé puis re-sérialisé au lieu des octets bruts de la requête.
• Utiliser une égalité de chaînes non sûre en temps (=== dans certains contextes) pour comparer des étiquettes dans du code haute assurance.
• Faire tourner les clés sans fenêtre de double vérification, provoquant des échecs soudains de vérification.

Limites et environnement

Ces outils navigateur aident à générer et comparer des digests en apprenant ou en déboguant. Ce ne sont pas un système de gestion de clés. Gardez les vrais secrets de production dans des magasins côté serveur ; utilisez des clés jetables pour les démos.

Résumé

HMAC transforme une fonction de hachage en authentificateur à clé. Ce hub fournit HMAC-MD5, HMAC-SHA-1 et HMAC-SHA-256 pour coller aux exigences de protocole et voir comment les digests changent avec message ou clé. Préférez SHA-256 pour un nouveau travail, canonicalisez les octets avant de signer, et souvenez-vous qu’HMAC authentifie—il ne chiffre pas.