Calculez une signature HMAC pour n'importe quel message et secret en utilisant SHA-1, SHA-256, SHA-384 ou SHA-512, avec une sortie hex, base64 ou base64url.
Codes d'authentification de message, localement. HMAC combine une fonction de hachage avec une clé secrète pour qu'un destinataire puisse vérifier à la fois l'intégrité et l'authenticité. Calculé dans votre navigateur via l'API Web Crypto.
Un HMAC ne cache rien. Il répond à une question différente : ce message exact a-t-il été produit par quelqu'un détenant le secret partagé, et a-t-il été altéré depuis ? La sortie est une balise de taille fixe que vous envoyez avec le message ; le destinataire la recalcule avec la même clé et la compare. Des balises correspondantes signifient que le message est authentique et intact. Des balises non correspondantes signifient qu'il n'est ni l'un ni l'autre, et il n'y a aucun moyen de savoir lequel.
Cela fait de HMAC la pièce maîtresse derrière les signatures de webhook, la signature de requêtes API, les cookies signés et les jetons de session. Stripe, GitHub et la plupart des fournisseurs de webhook signent leurs charges utiles de cette façon afin que vous puissiez vérifier qu'une requête vient vraiment d'eux plutôt que de quelqu'un ayant deviné l'URL de votre point de terminaison.
La construction évidente — SHA256(key + message) — est cassée contre les hachages Merkle-Damgard comme SHA-1 et SHA-256. Ces hachages traitent les données par blocs et propagent l'état, donc un attaquant connaissant un digest valide peut ajouter des données et calculer un digest valide pour le message étendu sans jamais apprendre la clé. C'est l'attaque par extension de longueur, et elle n'est pas théorique ; elle a cassé de vraies API.
La construction imbriquée de HMAC, H(key XOR opad || H(key XOR ipad || message)), bouche ce trou. Les deux passes avec des clés rembourrées différentes signifient que le digest final n'est pas l'état interne brut d'un hachage sur des données influencées par l'attaquant. C'est pourquoi vous devriez toujours utiliser HMAC plutôt qu'inventer votre propre hachage clé.
Choisissez SHA-256 à moins que quelque chose d'externe ne vous y force. SHA-1 reste sûr dans HMAC car la construction ne repose pas sur la résistance aux collisions, mais les nouveaux systèmes n'ont aucune raison de l'utiliser et les auditeurs le signaleront. SHA-512 n'est pas significativement plus fort à cette fin et est parfois plus rapide sur matériel 64 bits.
Deux détails d'implémentation comptent plus que le choix du hachage. D'abord, comparez les balises en temps constant — une comparaison de chaîne normale renvoie tôt au premier octet différent, ce qui fuit assez d'informations temporelles pour forger une balise un octet à la fois. Ensuite, les clés doivent être des octets aléatoires d'au moins la longueur du digest, pas une phrase de passe mémorisable ; les clés HMAC ne sont pas des hachages de mot de passe et ne bénéficient d'aucun étirement.