HMAC Generator

Eine Nachricht mit einem gemeinsamen Geheimnis signieren

1. Füge die Nachricht ein, die du authentifizieren möchtest, in das Nachrichten-Textarea. Das sind die Bytes, die signiert werden; von einem JSON-Webhook-Body bis zu einem Unicode-String funktioniert alles.
2. Gib das gemeinsame Geheimnis in das Schlüssel-Eingabefeld ein. In der Produktion ist das typischerweise ein 32-Byte-Zufallswert aus einem CSPRNG, als Hex oder Base64 kodiert; zum Testen wird jeder String akzeptiert.
3. Wähle den zugrundeliegenden Hash: SHA-1 für Legacy-Interoperabilität (AWS Signature v2, RFC 2104-Testvektoren), SHA-256 für fast alles Moderne (JWT HS256, Stripe-Webhooks, GitHub-Webhooks), SHA-384 für Payloads mit höherer Sicherheitsanforderung, SHA-512 wenn du das längere Tag benötigst.
4. Klicke auf "HMAC generieren". Das Tool importiert den Schlüssel über crypto.subtle.importKey mit dem passenden Algorithmusnamen (HMAC mit hash: 'SHA-256'), dann ruft es crypto.subtle.sign auf deinen Nachrichten-Bytes auf.
5. Kopiere den Hex-Digest und füge ihn in den X-Signature-Header ein (oder wohin auch immer deine API ihn erwartet). Auf der Empfangsseite berechnet der Server HMAC auf denselben Bytes mit demselben Schlüssel neu und vergleicht mit einer zeitkonstanten Gleichheitsprüfung.

Was HMAC löst, was ein einfacher Hash nicht kann

HMAC (Hash-basierter Nachrichtenauthentifizierungscode) ist in RFC 2104 und FIPS 198-1 spezifiziert: HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)), wobei K' der auf Blockgröße aufgefüllte Schlüssel ist, ipad = 0x36 wiederholt und opad = 0x5C wiederholt. Der doppelte Hash mit innerer/äußerer Auffüllung verhindert Längenerweiterungsangriffe auf rohe Merkle-Damgard SHA-1/SHA-256. Bei SHA256(key || msg) kann ein Angreifer, der ein gültiges Tag beobachtet, ein Tag für key || msg || padding || evil fälschen; HMAC verhindert dies. Die Web Crypto API stellt HMAC über crypto.subtle.sign und crypto.subtle.verify bereit, beide nativ implementiert (BoringSSL für Chromium, NSS für Firefox). Der verify-Pfad läuft in konstanter Zeit. Dieses Tool verwendet nur sign; im Produktions-Verifikationscode verwende immer verify statt Hex mit === zu vergleichen.

Wo HMAC in echten Systemen auftaucht

• Webhook-Signaturverifizierung: GitHub signiert Webhook-Bodies mit HMAC-SHA-256 im X-Hub-Signature-256-Header; Stripe verwendet Stripe-Signature mit HMAC-SHA-256; Slack nutzt ein versioniertes HMAC-SHA-256-Schema.
• JWT-Signierung für HS256/HS384/HS512-Algorithmen (RFC 7518), verwendet von Auth0, Clerk und jeder Bibliothek, die symmetrische JWTs unterstützt.
• AWS Signature Version 4 für alle REST-API-Aufrufe: Eine Kette von HMAC-SHA-256-Aufrufen leitet pro-Anfrage-, pro-Region-, pro-Service-Signaturschlüssel aus deinem geheimen Zugriffsschlüssel ab.
• TOTP und HOTP Einmalpasswort-Codes (RFC 6238, RFC 4226) berechnen HMAC-SHA-1 eines Zeitzählers und kürzen dynamisch auf 6 Stellen.
• Die TLS 1.2-Datensatzschicht verwendet HMAC für Nachrichtenintegrität in Cipher-Suites, die kein AEAD sind (obwohl TLS 1.3 vollständig zu AEAD gewechselt ist).
• Signierte URLs (S3 Presigned URLs, CloudFront Signed URLs, benutzerdefinierte CDN-Token-Authentifizierung) betten einen HMAC ein, den der Server vor dem Ausliefern der Ressource verifiziert.

Die Fehlermodi, die tatsächlich Ausfälle verursachen

Der häufigste HMAC-Implementierungsfehler ist der nicht-zeitkonstante Vergleich. Wenn du das empfangene Tag mit dem berechneten Tag mittels === oder == vergleichst, leckt der frühe Abbruch beim ersten Byte-Unterschied Timing-Informationen. Die Lösung ist crypto.subtle.verify, crypto.timingSafeEqual in Node, hmac.compare_digest in Python. Der zweite Fehler ist Schlüsselverwechslung zwischen Algorithmen: Wenn dein Server sowohl HS256 als auch HS384 akzeptiert, kann ein Angreifer Algorithmus-Header tauschen und mit einem längeren Schlüssel signieren. Pinne den Algorithmus auf der Serverseite. Drittens die Kanonisierung: HMAC signiert Bytes, also müssen Sender und Empfänger exakt dieselben Bytes vereinbaren. GitHub und Stripe signieren rohe Request-Bodies; wenn Middleware vor der Verifizierung re-serialisiert, stimmt das Tag nicht überein. Viertens müssen HMAC-Schlüssel wie jedes andere Geheimnis behandelt werden - ein geteilter Schlüssel im Quellcode ist ein Klartext-Passwort.

RFC 2104, FIPS 198-1 und warum HMAC seltsam aussieht

HMAC wurde 1996 von Bellare, Canetti und Krawczyk entworfen und in RFC 2104 (1997) als IETF-Antwort auf CBC-MAC-Fallstricke und die ad-hoc-"Geheimpräfix"-Schemata standardisiert, die es davor gab. Die innere-äußere Auffüllungsstruktur stellt sicher, dass HMAC ein sicherer MAC bleibt, selbst wenn die zugrundeliegende Hash-Funktion einige Kollisionsschwächen hat: HMAC-MD5 war noch sicher, lange nachdem MD5-Kollisionen gefunden wurden, weil Kollisionsresistenz nicht die Eigenschaft ist, die HMAC von seinem Hash benötigt. Was HMAC braucht, ist Pseudozufalls-Funktionsverhalten, das SHA-1, SHA-256 und SHA-512 alle bieten. Die Ausgabegröße entspricht der zugrundeliegenden Hash-Ausgabegröße: 20 Byte für HMAC-SHA-1, 32 Byte für HMAC-SHA-256, 64 Byte für HMAC-SHA-512. Kürzung ist erlaubt (RFC 2104 Abschnitt 5) bis auf die Hälfte der Hash-Ausgabe - HMAC-SHA-256-128 kürzt auf 16 Byte und ist noch sicher. Der Schlüssel kann jede Länge haben; wenn er länger als die Hash-Blockgröße (64 Byte für SHA-256, 128 für SHA-512) ist, wird er zuerst gehashed, also bringt ein 1-MB-Schlüssel nichts über die ersten blockgröße-gehashten Bytes hinaus.

HMAC vs. Poly1305, KMAC und asymmetrische Signaturen

HMAC ist der etablierte Standard; Poly1305 (RFC 8439, ChaCha20-Poly1305 AEAD) ist auf Plattformen ohne SHA-NI viel schneller als HMAC-SHA-256 und wird von TLS 1.3-Mobilverbindungen verwendet. KMAC (NIST SP 800-185) ist die SHA-3-basierte Alternative, sauberer aber nicht weit verbreitet. Für asymmetrisches Vertrauen, bei dem nur eine Partei den Signierschlüssel hat, verwende Ed25519 (RFC 8032) oder ECDSA - HMAC erfordert, dass beide Parteien das Geheimnis teilen. Praktische Empfehlung: Webhook-Signaturen, JWT HS-Prefix, AWS-Signierung, TOTP verwenden HMAC-SHA-256. Enge innere Schleifen verwenden Poly1305. Mehrparteien-Vertrauen verwendet Ed25519. Die begleitenden RSA- und TOTP-Tools auf dieser Seite decken diese Alternativen ab.