Générateur HMAC - Chiffrement HMAC

Générateur HMAC-SHA256/SHA-512/SHA-1 — signez webhooks, requêtes AWS, tokens JWT HS256. Sortie hex ou Base64. WebCrypto, 100% navigateur.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Générateur HMAC - Générer Codes Authentification Message en Ligne

HMAC (Hash-based Message Authentication Code) est la primitive cryptographique qui alimente pratiquement tous les schémas d'authentification API en production : AWS Signature v4, signatures de webhook Stripe, secrets GitHub Actions, vérification de requêtes Slack, signature de requêtes Twilio, callbacks d'événements Mailgun, chaque JWT avec un alg HS256/HS384/HS512, et toute la spec de tokens MAC OAuth 2.0 se réduisent à HMAC en leur cœur. Standardisé dans la RFC 2104 (Krawczyk, Bellare, Canetti, 1997) et prouvé sûr sous hypothèses standard sur le hash sous-jacent, HMAC prend deux entrées — une CLÉ secrète partagée et un MESSAGE — et produit une signature de taille fixe que quiconque possède la clé peut redériver et comparer. C'est fondamentalement différent d'un hash brut comme sha256(message) : sans la clé, un attaquant peut calculer son propre sha256 de tout message falsifié et remplacer le vôtre ; avec HMAC, ils ne peuvent pas forger une signature correspondante sans connaître la clé. Ce générateur exécute l'implémentation WebCrypto complète côté client et supporte les trois variantes de la famille SHA-2 (SHA-256 pour la plupart des usages modernes, SHA-512 pour les applications haute sécurité, SHA-1 pour les systèmes legacy dont vous devriez vous éloigner), avec sortie à la fois hexadécimale (le format universel text-safe pour en-têtes et fichiers de config) et base64 (le standard pour signatures JWT et de nombreuses APIs auth). Ne réutilisez jamais un secret entre services, ne l'intégrez jamais dans le code côté client, et faites-le tourner périodiquement. Voir aussi notre Générateur Hash SHA-512 et Générateur Hash MD5.

Qu'est-ce que HMAC ?

HMAC (Hash-based Message Authentication Code) est un algorithme cryptographique qui combine une fonction de hachage avec une clé secrète pour créer un code d'authentification de message.

Caractéristiques clés :
- Vérifie à la fois intégrité et authenticité données
- Nécessite clé secrète (partagée entre émetteur/récepteur)
- Basé sur fonctions hachage standard (SHA-256, SHA-512, etc.)
- Utilisé dans API, JWT, webhooks et communications sécurisées

HMAC = Hash(clé_secrète + message)

Exemple :
Message : "Bonjour, Monde !"
Secret : "maCleSec rète"
HMAC-SHA256 : a4e624d686e03ed2767c0abd85c14426b0b1157d2ce81d27bb4fe4bc1e4fa3a6

Comment générer un HMAC ?

1. Entrez votre message/données
2. Entrez votre clé secrète
3. Sélectionnez algorithme hash (SHA-256 recommandé)
4. Choisissez format sortie (hex ou base64)
5. Cliquez 'Générer HMAC'
6. Copiez le code HMAC

Exemple :
Message : "utilisateur=jean&action=connexion"
Clé : "cle_secrete_api_123"
Algorithme : HMAC-SHA256
Sortie : chaîne hex 64-caractères

Le même message + clé produira toujours le même HMAC.

À quoi sert HMAC ?

HMAC est largement utilisé pour authentification sécurisée et vérification intégrité :

✓ Authentification API :
- Vérification signature AWS
- Webhooks GitHub
- Signature requêtes API
- Signatures OAuth

✓ JWT (JSON Web Tokens) :
- Algorithmes HS256, HS384, HS512
- Vérification signature token

✓ Intégrité Message :
- Vérification payload webhook
- Détection altération données
- Transmission message sécurisée

✓ Gestion Session :
- Signature cookie
- Génération token CSRF
- Validation session

HMAC assure à la fois authenticité (émetteur a la clé) et intégrité (message inchangé).

Quel algorithme HMAC dois-je utiliser ?

Choisissez selon vos besoins sécurité :

HMAC-SHA256 (Recommandé) :
✓ Standard industriel
✓ Rapide et sécurisé
✓ Sortie hex 64-caractères
✓ Utilisé par plupart API
✓ JWT HS256

HMAC-SHA512 (Plus Sûr) :
✓ Sécurité maximale
✓ Sortie hex 128-caractères
✓ Meilleur pour données haute valeur
✓ JWT HS512

HMAC-SHA1 (Hérité) :
⚠️ Déprécié pour nouveaux projets
✓ Seulement pour compatibilité héritée
✓ Sortie hex 40-caractères

Pour la plupart applications : Utilisez HMAC-SHA256
Pour sécurité maximale : Utilisez HMAC-SHA512
Évitez SHA-1 pour nouveaux projets.

Générateur HMAC - Chiffrement HMAC — Générateur HMAC-SHA256/SHA-512/SHA-1 — signez webhooks, requêtes AWS, tokens JWT HS256. Sortie hex ou Base64. WebCrypto, — **Générateur HMAC - Chiffrement HMAC**

Comment HMAC vérifie-t-il les messages ?

Processus vérification HMAC :

1. Émetteur :
- Crée message
- Génère HMAC avec clé secrète
- Envoie message + HMAC

2. Récepteur :
- Reçoit message + HMAC
- Génère HMAC depuis message avec même clé
- Compare HMAC généré avec HMAC reçu
- Correspondance = authentique, pas d'altération
- Non-correspondance = rejeter (altéré ou mauvaise clé)

Exemple :
Message : "virement 100€"
Clé : "secret_partagé"
HMAC : abc123...

Si attaquant change en "virement 1000€" :
- Nouveau HMAC ne correspondra pas
- Récepteur rejette le message

HMAC protège contre altération et assure authenticité émetteur.

Comment vérifier une signature de webhook Stripe / GitHub / Slack avec HMAC ?

Les trois suivent le même schéma avec des détails différents. Le fournisseur de webhook POST un payload JSON à votre endpoint accompagné d'un en-tête contenant une signature HMAC de ce payload exact, calculée avec un secret partagé que vous avez configuré lors du setup du webhook. Votre travail : recalculer le HMAC sur le body reçu et comparer avec la valeur de l'en-tête en utilisant une comparaison à TEMPS CONSTANT (==, ===, strcmp fuient l'info de timing ; utilisez crypto.timingSafeEqual en Node ou hmac.compare_digest en Python). S'ils correspondent, la requête vient vraiment du fournisseur et n'a pas été altérée en transit ; sinon, rejetez avec 401. (1) Stripe : en-tête 'Stripe-Signature: t=1234567890,v1=abc...', secret commence par 'whsec_', algorithme HMAC-SHA256, payload signé est timestamp + '.' + body. (2) GitHub : en-tête 'X-Hub-Signature-256: sha256=abc...', secret que vous définissez par repo, HMAC-SHA256 du body brut. (3) Slack : en-tête 'X-Slack-Signature: v0=abc...', signing secret de la config de l'app, HMAC-SHA256 de 'v0:' + timestamp + ':' + body. Rejetez aussi toujours si le timestamp a plus de 5 minutes pour empêcher les attaques par rejeu.

Pourquoi mon HMAC calculé en Python ne correspond-il pas à celui de Node.js ?

Huit fois sur dix c'est un décalage d'encodage — vous hashez des séquences d'octets différentes sans vous en rendre compte. Passez par cette checklist. (1) Encodage de la clé : en JavaScript 'Buffer.from(secret)' suppose UTF-8 par défaut mais '.from(secret, 'hex')' interprète la même chaîne comme octets hex. Si votre secret ressemble à '00ff42' ça pourrait être une valeur hex de 3 octets OU une chaîne UTF-8 de 6 octets '00ff42'. (2) Encodage du message : même problème. La sérialisation JSON doit produire exactement les mêmes octets des deux côtés — même les différences d'ordre des clés ({a:1,b:2} vs {b:2,a:1}) produisent des signatures différentes. La plupart des APIs requièrent que vous signiez la séquence d'octets JSON brute envoyée par le client, pas une version re-sérialisée. (3) Encodage de sortie : hex vs base64 vs base64 URL-safe diffèrent. (4) Sauts de ligne : \n sur Linux/Mac mais \r\n dans le body de requête depuis un client Windows ; HMAC les voit comme des octets différents. (5) Espaces : espaces en fin de message. Solution : affichez les octets exacts (Buffer.from(...).toString('hex')) des deux côtés pour un petit message de test connu jusqu'à ce qu'ils correspondent, puis passez au payload réel.

Puis-je utiliser HMAC pour mots de passe ?

NON ! HMAC n'est PAS pour hachage mots de passe.

HMAC :
✓ Authentification message
✓ Signatures API
✓ Intégrité données
✗ PAS stockage mot de passe

Pour mots de passe, utilisez :
✓ bcrypt (recommandé)
✓ Argon2 (moderne)
✓ PBKDF2 (acceptable)

Pourquoi ?
- HMAC est rapide (pas bon pour mots de passe)
- HMAC nécessite une clé (mots de passe sont le secret)
- HMAC n'utilise pas salt correctement pour mots de passe

HMAC et hachage mot de passe servent objectifs différents !