CodeKitHubHvad er dette værktøj?
HMAC står for Hash-based Message Authentication Code. Den kombinerer en hemmelig nøgle med en besked og en standard hashfunktion (som SHA-256) for at producere et digest med fast længde. Alle med samme nøgle og besked vil beregne præcis samme HMAC — men uden nøglen er det beregningsmæssigt umuligt at producere en gyldig HMAC for en besked, selv hvis du kender den anvendte hashalgoritme.
Det er den centrale forskel fra en almindelig hash: en almindelig hash (MD5, SHA-256 osv.) tager kun beskeden som input, så alle kan beregne den, og den beviser intet om, hvem der har oprettet den. En HMAC tager beskeden *og* en hemmelig nøgle, så en gyldig HMAC beviser, at afsenderen besad hemmeligheden — det er en autentificeringsmekanisme, ikke bare en integritetskontrol.
HMAC er formelt standardiseret af NIST i FIPS 198-1 og defineret for internetprotokoller i IETF RFC 2104. Dette værktøj beregner HMAC'er ved hjælp af din browsers native Web Crypto API (`crypto.subtle.sign` med HMAC-algoritmen), som implementerer RFC 2104 korrekt frem for en håndlavet JavaScript-version.
Hvorfor bruge det?
- Signer API-anmodninger, så den modtagende server kan verificere, at anmodningen kommer fra en indehaver af den delte hemmelighed og ikke er blevet manipuleret.
- Verificer webhook-payloads (Stripe, GitHub, Shopify og lignende tjenester signerer alle webhook-bodies med HMAC-SHA256).
- Generer autentificeringstokens eller engangskoder, der afhænger af en delt hemmelighed.
- Sammenlign din egen HMAC-implementerings output med en kendt korrekt referenceværdi.
- 100 % lokalt: din hemmelige nøgle og besked forlader aldrig browseren, så det er sikkert at teste rigtige hemmeligheder.
Sådan bruger du det
- Indtast din hemmelige nøgle i feltet "Hemmelig nøgle".
- Indtast den besked, du vil autentificere, i feltet "Besked".
- HMAC-SHA1-, HMAC-SHA256-, HMAC-SHA384- og HMAC-SHA512-resultaterne genereres øjeblikkeligt (marker "Output med store bogstaver", hvis dit målsystem forventer store bogstaver).
- Klik på "Kopiér" ved siden af den HMAC, du har brug for.
Eksempel
Input
Hemmelig nøgle: key
Besked: The quick brown fox jumps over the lazy dogOutput
HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9Dette er en standard, offentliggjort testvektor: med nøglen "key" og præcis denne besked producerer HMAC-SHA256 og HMAC-SHA1 altid disse værdier i enhver korrekt implementering, så du kan verificere dette værktøjs output uafhængigt.
HMAC vs. almindelig hash: hvornår du har brug for en nøgle
Det afgørende spørgsmål er: skal du bevise, hvem der oprettede dette digest, eller bare at indholdet ikke er ændret? Hvis en offentlig kontrolsum er nok — verifikation af, at en downloadet fil matcher det, udgiveren har angivet, deduplikering af poster — fungerer en almindelig hash, og alle kan kontrollere den, uden nøgle. Hvis du skal bevise, at digestet kun kunne være produceret af nogen, der besidder en bestemt hemmelighed — autentificering af en API-kalder, tillid til en webhook-afsender — har du brug for HMAC, fordi en almindelig hash giver en angriber uden hemmelighed samme mulighed for at forfalske et gyldigt digest som den rigtige afsender.
→ Multi-algoritme hash-generator · JWT-dekoder · MD5-generator
Sammenligning af de fire HMAC-algoritmer
Alle fire bruger den samme HMAC-konstruktion fra RFC 2104, og adskiller sig kun i den underliggende hashfunktion og dermed i outputlængden.
| Algoritme | Outputstørrelse | Typisk anvendelse |
|---|---|---|
| HMAC-SHA1 | 160 bit (40 hex-tegn) | Ældre API'er, ældre OAuth 1.0a-signaturer |
| HMAC-SHA256 | 256 bit (64 hex-tegn) | API-anmodningssignering, JWT HS256, webhook-verifikation |
| HMAC-SHA384 | 384 bit (96 hex-tegn) | Signaturer med højere sikkerhed, hvor længere output kræves |
| HMAC-SHA512 | 512 bit (128 hex-tegn) | Digests med maksimal længde til applikationer med høj sikkerhed |
Almindelige anvendelsestilfælde
- Signering af udgående API-anmodninger med en delt hemmelighed, så serveren kan verificere den kaldendes identitet.
- Verifikation af indgående webhook-payloads (Stripe-Signature, GitHub X-Hub-Signature-256 og lignende headere bruger alle HMAC-SHA256).
- Generering og validering af signaturdelen af en JWT signeret med HS256/HS384/HS512.
- Test af, at din server- eller klientsides HMAC-implementering matcher det forventede output, før den udrulles.
Ofte stillede spørgsmål
Hvad er HMAC?
HMAC (Hash-based Message Authentication Code) kombinerer en hemmelig nøgle med en besked ved hjælp af en hashfunktion for at producere et digest, der beviser både beskedens integritet og afsenderens besiddelse af nøglen. Den er defineret i NIST FIPS 198-1 og IETF RFC 2104.
Hvad er forskellen mellem HMAC og en almindelig hash?
En almindelig hash (SHA-256, MD5 osv.) tager kun en besked som input — alle kan beregne den, så den beviser kun, at beskeden ikke er blevet ødelagt, ikke hvem der sendte den. En HMAC tager en besked plus en hemmelig nøgle: hvis du skal bevise, at en besked kommer fra nogen, der besidder en bestemt hemmelighed (en API-signatur, en webhook-afsender), har du brug for HMAC. Hvis du kun skal kontrollere, at en fil eller besked ikke er ændret, og ikke er interesseret i at bevise ophavsret, er en almindelig hash nok.
Sendes min hemmelige nøgle til en server?
Nej. Dette værktøj beregner HMAC'en fuldstændigt i din browser ved hjælp af Web Crypto API. Din nøgle og besked overføres aldrig nogen steder — du kan trygt teste rigtige produktionshemmeligheder.
Hvilken algoritme skal jeg bruge — SHA-1, SHA-256, SHA-384 eller SHA-512?
Brug HMAC-SHA256, medmindre et bestemt system kræver andet — det er de facto-standarden for API-signering (bruges af AWS, Stripe, GitHub-webhooks og de fleste moderne API'er) og tilbyder en stærk sikkerhedsmargin. HMAC-SHA1 er stadig almindelig i ældre systemer (som ældre OAuth 1.0a-implementeringer), men SHA-1's underliggende hash anses for svagere; HMAC-SHA384/512 bruges, hvor længere output eller ekstra sikkerhedsmargin specifikt kræves.
Er HMAC-SHA1 usikker, når almindelig SHA-1 er brudt?
Kollisionsangrebene fra 2017 brød SHA-1 som en almindelig hashfunktion, men HMAC-SHA1 anses stadig for kryptografisk sikker, fordi HMAC's sikkerhed ikke afhænger af kollisionsmodstand på samme måde. Alligevel bør du foretrække HMAC-SHA256 eller højere til nye systemer — der er ingen praktisk ulempe, og det undgår spørgsmålet helt.
Hvad er almindelige virkelige anvendelser af HMAC?
Signering af REST API-anmodninger, så en server kan verificere, at den, der kalder, besidder den delte API-hemmelighed; verificering af webhook-payloads fra tjenester som Stripe, GitHub og Shopify, så du ved, at en anmodning virkelig kommer fra dem og ikke er forfalsket; generering af tidsbaserede engangskoder (TOTP/HOTP) til tofaktorautentificering; og signering af JWT-tokens med algoritmerne HS256/HS384/HS512.