CodeKitHubWat is deze tool?
HMAC staat voor Hash-based Message Authentication Code. Het combineert een geheime sleutel met een bericht en een standaard hashfunctie (zoals SHA-256) om een digest met vaste lengte te produceren. Iedereen met dezelfde sleutel en hetzelfde bericht berekent exact dezelfde HMAC — maar zonder de sleutel is het computationeel onhaalbaar om een geldige HMAC voor een bericht te produceren, zelfs als je het gebruikte hashalgoritme kent.
Dat is het belangrijkste verschil met een gewone hash: een gewone hash (MD5, SHA-256, enz.) neemt alleen het bericht als invoer, dus iedereen kan hem berekenen en hij bewijst niets over wie hem heeft gemaakt. Een HMAC neemt het bericht *en* een geheime sleutel, dus een geldige HMAC bewijst dat de afzender het geheim bezat — het is een authenticatiemechanisme, geen loutere integriteitscontrole.
HMAC is formeel gestandaardiseerd door NIST in FIPS 198-1 en gedefinieerd voor internetprotocollen in IETF RFC 2104. Deze tool berekent HMAC's met de native Web Crypto API van je browser (`crypto.subtle.sign` met het HMAC-algoritme), die RFC 2104 correct implementeert in plaats van een handmatig geschreven JavaScript-versie.
Waarom gebruiken?
- Onderteken API-verzoeken zodat de ontvangende server kan verifiëren dat het verzoek afkomstig is van een houder van het gedeelde geheim en niet is gemanipuleerd.
- Verifieer webhook-payloads (Stripe, GitHub, Shopify en soortgelijke diensten ondertekenen allemaal hun webhook-berichten met HMAC-SHA256).
- Genereer authenticatietokens of eenmalige codes die afhankelijk zijn van een gedeeld geheim.
- Vergelijk de output van je eigen HMAC-implementatie met een bekende, correcte referentiewaarde.
- 100% lokaal: je geheime sleutel en bericht verlaten nooit de browser, dus het is veilig om echte geheimen te testen.
Hoe te gebruiken
- Voer je geheime sleutel in het veld "Secret Key" in.
- Voer het bericht dat je wilt authenticeren in het veld "Message" in.
- De resultaten voor HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 en HMAC-SHA512 worden direct gegenereerd (vink "Uppercase output" aan als je doelsysteem hoofdletters verwacht).
- Klik op "Copy" naast de HMAC die je nodig hebt.
Voorbeeld
Invoer
Secret Key: key
Message: The quick brown fox jumps over the lazy dogUitvoer
HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9Dit is een standaard gepubliceerde testvector: met sleutel "key" en dit exacte bericht produceren HMAC-SHA256 en HMAC-SHA1 altijd deze waarden bij elke correcte implementatie, zodat je de output van deze tool onafhankelijk kunt verifiëren.
HMAC versus gewone hash: wanneer heb je een sleutel nodig
De doorslaggevende vraag is: moet je bewijzen wie deze digest heeft gemaakt, of alleen dat de inhoud niet is gewijzigd? Als een publieke checksum volstaat — verifiëren dat een gedownload bestand overeenkomt met wat de uitgever heeft vermeld, records dedupliceren — werkt een gewone hash en kan iedereen die controleren, zonder sleutel. Als je moet bewijzen dat de digest alleen geproduceerd kon zijn door iemand die een specifiek geheim bezit — een API-aanroeper authenticeren, de afzender van een webhook vertrouwen — heb je HMAC nodig, omdat een gewone hash een aanvaller zonder geheim dezelfde mogelijkheid geeft om een geldige digest te vervalsen als de echte afzender.
→ Multi-Algorithm Hash Generator · JWT Decoder · MD5 Generator
De vier HMAC-algoritmen vergeleken
Alle vier gebruiken dezelfde HMAC-constructie uit RFC 2104, met als enige verschil de onderliggende hashfunctie en dus de lengte van de output.
| Algoritme | Outputgrootte | Typisch gebruik |
|---|---|---|
| HMAC-SHA1 | 160-bit (40 hex-tekens) | Legacy-API's, oudere OAuth 1.0a-handtekeningen |
| HMAC-SHA256 | 256-bit (64 hex-tekens) | API-verzoekondertekening, JWT HS256, webhook-verificatie |
| HMAC-SHA384 | 384-bit (96 hex-tekens) | Handtekeningen met hogere zekerheid waar langere output vereist is |
| HMAC-SHA512 | 512-bit (128 hex-tekens) | Digests met maximale lengte voor toepassingen met hoge beveiligingseisen |
Veelvoorkomende toepassingen
- Uitgaande API-verzoeken ondertekenen met een gedeeld geheim zodat de server de identiteit van de aanroeper kan verifiëren.
- Inkomende webhook-payloads verifiëren (Stripe-Signature, GitHub X-Hub-Signature-256 en soortgelijke headers gebruiken allemaal HMAC-SHA256).
- Het signatuurgedeelte van een JWT ondertekend met HS256/HS384/HS512 genereren en valideren.
- Testen of je server- of clientzijdige HMAC-implementatie overeenkomt met de verwachte output voordat je deze implementeert.
Veelgestelde vragen
Wat is HMAC?
HMAC (Hash-based Message Authentication Code) combineert een geheime sleutel met een bericht met behulp van een hashfunctie om een digest te produceren die zowel de integriteit van het bericht als het bezit van de sleutel door de afzender bewijst. Het is gedefinieerd in NIST FIPS 198-1 en IETF RFC 2104.
Wat is het verschil tussen HMAC en een gewone hash?
Een gewone hash (SHA-256, MD5, enz.) neemt alleen een bericht als invoer — iedereen kan hem berekenen, dus hij bewijst alleen dat het bericht niet corrupt is geraakt, niet wie het verstuurde. Een HMAC neemt een bericht plus een geheime sleutel: als je moet bewijzen dat een bericht afkomstig is van iemand die een specifiek geheim bezit (een API-handtekening, een webhook-afzender), heb je HMAC nodig. Als je alleen hoeft te controleren dat een bestand of bericht niet is gewijzigd en het je niet uitmaakt wie het auteurschap bewijst, volstaat een gewone hash.
Wordt mijn geheime sleutel naar een server verzonden?
Nee. Deze tool berekent de HMAC volledig in je browser met de Web Crypto API. Je sleutel en bericht worden nooit ergens naartoe verzonden — je kunt veilig echte productiegeheimen testen.
Welk algoritme moet ik gebruiken — SHA-1, SHA-256, SHA-384 of SHA-512?
Gebruik HMAC-SHA256 tenzij een specifiek systeem anders vereist — het is de de-facto standaard voor API-ondertekening (gebruikt door AWS, Stripe, GitHub-webhooks en de meeste moderne API's) en biedt een sterke veiligheidsmarge. HMAC-SHA1 komt nog vaak voor in legacy-systemen (zoals oudere OAuth 1.0a-implementaties), maar de onderliggende hash van SHA-1 wordt als zwakker beschouwd; HMAC-SHA384/512 worden gebruikt waar specifiek een langere output of extra veiligheidsmarge vereist is.
Is HMAC-SHA1 onveilig, aangezien gewone SHA-1 gebroken is?
De botsingsaanvallen van 2017 braken SHA-1 als gewone hashfunctie, maar HMAC-SHA1 wordt nog steeds als cryptografisch degelijk beschouwd, omdat de veiligheid van HMAC niet op dezelfde manier afhankelijk is van botsingsbestendigheid. Geef desondanks voor nieuwe systemen de voorkeur aan HMAC-SHA256 of hoger — er is geen praktisch nadeel en het vermijdt de vraag volledig.
Wat zijn veelvoorkomende praktische toepassingen van HMAC?
Het ondertekenen van REST API-verzoeken zodat een server kan verifiëren dat de aanroeper het gedeelde API-geheim bezit; het verifiëren van webhook-payloads van diensten zoals Stripe, GitHub en Shopify zodat je weet dat een verzoek werkelijk van hen afkomstig is en niet vervalst; het genereren van tijdgebonden eenmalige wachtwoorden (TOTP/HOTP) voor tweefactorauthenticatie; en het ondertekenen van JWT-tokens met de HS256/HS384/HS512-algoritmen.