Générateur HMAC

HMAC est l’algorithme derrière la plupart des webhooks signés, des en-têtes AWS Signature v4 et des tokens JWT HS256. Entrez un message et une clé secrète, choisissez une famille de hachage, et ce générateur produit l’HMAC exactement comme spécifié par la RFC 2104, utile pour vérifier ce que votre backend s’apprête à envoyer, ou reproduire une signature que vous avez reçue d’une API.

Comment calculer un HMAC

  1. 1

    Collez le message

    Les octets exacts à signer, une charge utile de webhook, une requête canonique, ou toute chaîne.

  2. 2

    Entrez la clé secrète

    Peut être du texte ou hexadécimal. Le générateur le complète ou le hache à la taille de bloc selon la RFC.

  3. 3

    Choisissez l'algorithme de hachage

    SHA-256 est par défaut ; choisissez SHA-1, SHA-384, SHA-512 ou MD5 pour la compatibilité avec les anciens systèmes.

  4. 4

    Copiez la signature

    La sortie est en hexadécimal minuscules, prête à coller dans une configuration de webhook ou un en-tête d'autorisation.

HMAC sous le capot

HMAC enveloppe une fonction de hachage simple dans une construction avec clé afin que la signature ne puisse pas être falsifiée sans la clé.

La recette de la RFC 2104

HMAC(k, m) = H((k' ⊕ opad) ∥ H((k' ⊕ ipad) ∥ m))

k' est la clé complétée à la taille de bloc de hachage, opad = 0x5c répété et ipad = 0x36 répété.

Choix d’algorithmes

Algorithme Taille de bloc Longueur de sortie Recommandé pour
HMAC-SHA-256 64 octets 32 octets Par défaut moderne, signature de webhook
HMAC-SHA-384 128 octets 48 octets Signature API de haute sécurité
HMAC-SHA-512 128 octets 64 octets Tokens à longue durée
HMAC-SHA-1 64 octets 20 octets Héritage (AWS S3 v2, OAuth 1.0)
HMAC-MD5 64 octets 16 octets Héritage uniquement ; à éviter pour les nouveaux travaux

Où apparaît HMAC

  • Webhooks GitHub, Stripe, Shopify : en-tête X-Hub-Signature-256, Stripe-Signature, etc.
  • AWS Signature v4 : une chaîne de HMAC-SHA256 sur la requête canonique.
  • JWT HS256 : la signature du token est HMAC-SHA-256(header.payload, secret).
  • Tokens de réinitialisation de mot de passe : HMAC sur user_id + expiration + un secret de site.

Erreurs courantes

  • Passer une clé encodée en hexadécimal comme texte au lieu de la décoder en octets d’abord.
  • Signer les mauvais octets de charge utile : certains webhooks signent le corps brut de la requête y compris les espaces, d’autres signent une forme canonique.
  • Utiliser == en JavaScript ou Python pour comparer les signatures ; utilisez toujours une comparaison sécurisée par le temps pour résister aux attaques par temporisation.

Questions fréquentes

Presque toujours parce que les octets du message diffèrent. Signer le corps analysé en JSON introduit des changements d’espaces ; signez le corps brut de la requête. Vérifiez également que la clé est décodée de la même manière (hex vs octets bruts) des deux côtés.

Oui. Si la clé est plus courte que la taille de bloc de hachage, elle est complétée par des zéros ; si elle est plus longue, elle est d’abord hachée. La RFC 2104 recommande des clés d’au moins la longueur de la sortie (32 octets pour SHA-256).

HMAC est toujours résistant aux attaques de collision MD5 connues car l’attaque ne se propage pas à la construction HMAC. Cependant, utilisez HMAC-SHA-256 pour tout nouveau code, les outils et les auditeurs s’y attendent.

Oui. Le message et la clé secrète sont envoyés à notre serveur via une connexion HTTPS chiffrée pour calculer le HMAC. Ils ne servent qu’au calcul et ne sont ni stockés ni journalisés.

Outils similaires

Outil disponible dans d’autres langues