CodeKitHubHva er dette verktøyet?
HMAC står for Hash-based Message Authentication Code. Den kombinerer en hemmelig nøkkel med en melding og en standard hash-funksjon (som SHA-256) for å produsere et sammendrag med fast lengde. Alle med samme nøkkel og melding vil beregne nøyaktig samme HMAC — men uten nøkkelen er det beregningsmessig umulig å produsere en gyldig HMAC for en melding, selv om du kjenner hash-algoritmen som brukes.
Det er hovedforskjellen fra en vanlig hash: en vanlig hash (MD5, SHA-256 osv.) tar bare meldingen som input, så hvem som helst kan beregne den, og den beviser ingenting om hvem som opprettet den. En HMAC tar meldingen *og* en hemmelig nøkkel, så en gyldig HMAC beviser at avsenderen hadde hemmeligheten — det er en autentiseringsmekanisme, ikke bare en integritetssjekk.
HMAC er formelt standardisert av NIST i FIPS 198-1 og definert for internettprotokoller i IETF RFC 2104. Dette verktøyet beregner HMAC-er med nettleserens native Web Crypto API (`crypto.subtle.sign` med HMAC-algoritmen), som implementerer RFC 2104 korrekt i stedet for en håndskrevet JavaScript-versjon.
Hvorfor bruke det?
- Signer API-forespørsler slik at mottakerserveren kan bekrefte at forespørselen kom fra en som innehar den delte hemmeligheten og ikke ble manipulert.
- Bekreft webhook-nyttelaster (Stripe, GitHub, Shopify og lignende tjenester signerer alle webhook-innholdet sitt med HMAC-SHA256).
- Generer autentiseringstokener eller engangskoder som er avhengige av en delt hemmelighet.
- Sammenlign din egen HMAC-implementasjons resultat mot en kjent, korrekt referanseverdi.
- 100 % lokalt: den hemmelige nøkkelen og meldingen din forlater aldri nettleseren, så det er trygt å teste ekte hemmeligheter.
Slik bruker du det
- Skriv inn din hemmelige nøkkel i feltet «Secret Key».
- Skriv inn meldingen du vil autentisere, i feltet «Message».
- Resultatene for HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 og HMAC-SHA512 genereres umiddelbart (kryss av «Uppercase output» hvis målsystemet ditt forventer store bokstaver).
- Klikk «Copy» ved siden av HMAC-en du trenger.
Eksempel
Inndata
Secret Key: key
Message: The quick brown fox jumps over the lazy dogResultat
HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9Dette er en standard publisert testvektor: med nøkkelen «key» og akkurat denne meldingen produserer HMAC-SHA256 og HMAC-SHA1 alltid disse verdiene i enhver korrekt implementasjon, så du kan verifisere dette verktøyets resultat uavhengig.
HMAC mot vanlig hash: når trenger du en nøkkel
Det avgjørende spørsmålet er: trenger du å bevise hvem som opprettet dette sammendraget, eller bare at innholdet ikke er endret? Hvis en offentlig sjekksum er nok — for å verifisere at en nedlastet fil samsvarer med det utgiveren oppga, eller for å deduplisere poster — fungerer en vanlig hash, og hvem som helst kan sjekke den, uten nøkkel. Hvis du trenger å bevise at sammendraget bare kunne vært produsert av noen som har en bestemt hemmelighet — autentisere en API-kaller, stole på avsenderen av en webhook — trenger du HMAC, fordi en vanlig hash gir en angriper uten hemmelighet samme mulighet til å forfalske et gyldig sammendrag som den ekte avsenderen har.
→ Multi-Algorithm Hash Generator · JWT Decoder · MD5 Generator
Sammenligning av de fire HMAC-algoritmene
Alle fire bruker samme HMAC-konstruksjon fra RFC 2104, og skiller seg bare i den underliggende hash-funksjonen og dermed lengden på resultatet.
| Algoritme | Resultatstørrelse | Typisk bruk |
|---|---|---|
| HMAC-SHA1 | 160-bit (40 heksadesimale tegn) | Eldre API-er, eldre OAuth 1.0a-signaturer |
| HMAC-SHA256 | 256-bit (64 heksadesimale tegn) | API-forespørselsignering, JWT HS256, webhook-verifisering |
| HMAC-SHA384 | 384-bit (96 heksadesimale tegn) | Signaturer med høyere sikkerhet der lengre resultat kreves |
| HMAC-SHA512 | 512-bit (128 heksadesimale tegn) | Sammendrag med maksimal lengde for høysikkerhetsapplikasjoner |
Vanlige bruksområder
- Signering av utgående API-forespørsler med en delt hemmelighet slik at serveren kan bekrefte den kallendes identitet.
- Bekreftelse av innkommende webhook-nyttelaster (Stripe-Signature, GitHub X-Hub-Signature-256 og lignende headere bruker alle HMAC-SHA256).
- Generering og validering av signaturdelen av en JWT signert med HS256/HS384/HS512.
- Testing av at din server- eller klientsidens HMAC-implementasjon samsvarer med forventet resultat før den tas i bruk.
Ofte stilte spørsmål
Hva er HMAC?
HMAC (Hash-based Message Authentication Code) kombinerer en hemmelig nøkkel med en melding ved hjelp av en hash-funksjon for å produsere et sammendrag som beviser både meldingens integritet og at avsenderen har nøkkelen. Den er definert i NIST FIPS 198-1 og IETF RFC 2104.
Hva er forskjellen mellom HMAC og en vanlig hash?
En vanlig hash (SHA-256, MD5 osv.) tar bare en melding som input — hvem som helst kan beregne den, så den beviser bare at meldingen ikke er ødelagt, ikke hvem som sendte den. En HMAC tar en melding pluss en hemmelig nøkkel: hvis du trenger å bevise at en melding kom fra noen som har en bestemt hemmelighet (en API-signatur, en webhook-avsender), trenger du HMAC. Hvis du bare trenger å sjekke at en fil eller melding ikke er endret og ikke bryr deg om å bevise forfatterskap, er en vanlig hash nok.
Sendes den hemmelige nøkkelen min til en server?
Nei. Dette verktøyet beregner HMAC-en helt og holdent i nettleseren din ved hjelp av Web Crypto API. Nøkkelen og meldingen din overføres aldri noe sted — du kan trygt teste ekte produksjonshemmeligheter.
Hvilken algoritme bør jeg bruke — SHA-1, SHA-256, SHA-384 eller SHA-512?
Bruk HMAC-SHA256 med mindre et spesifikt system krever noe annet — det er den de facto standarden for API-signering (brukt av AWS, Stripe, GitHub-webhooks og de fleste moderne API-er) og gir en solid sikkerhetsmargin. HMAC-SHA1 er fortsatt vanlig i eldre systemer (som eldre OAuth 1.0a-implementasjoner), men den underliggende hashen til SHA-1 anses som svakere; HMAC-SHA384/512 brukes der lengre output eller ekstra sikkerhetsmargin spesifikt kreves.
Er HMAC-SHA1 usikker, siden vanlig SHA-1 er knekt?
Kollisjonsangrepene i 2017 knekte SHA-1 som en vanlig hash-funksjon, men HMAC-SHA1 anses fortsatt som kryptografisk solid fordi HMAC-ens sikkerhet ikke er avhengig av kollisjonsmotstand på samme måte. Likevel bør du foretrekke HMAC-SHA256 eller høyere for nye systemer — det er ingen praktisk ulempe, og det unngår spørsmålet helt.
Hva er vanlige praktiske bruksområder for HMAC?
Signering av REST API-forespørsler slik at en server kan bekrefte at den som kaller har den delte API-hemmeligheten; bekreftelse av webhook-nyttelaster fra tjenester som Stripe, GitHub og Shopify slik at du vet at en forespørsel virkelig kom fra dem og ikke er forfalsket; generering av tidsbaserte engangspassord (TOTP/HOTP) for topartsautentisering; og signering av JWT-tokener med HS256/HS384/HS512-algoritmene.