HMAC-Generator

Was ist dieses Tool?

HMAC steht für Hash-based Message Authentication Code. Er kombiniert einen geheimen Schlüssel mit einer Nachricht und einer Standard-Hashfunktion (wie SHA-256), um einen Digest fester Länge zu erzeugen. Wer denselben Schlüssel und dieselbe Nachricht besitzt, berechnet exakt denselben HMAC — ohne den Schlüssel ist es jedoch praktisch unmöglich, einen gültigen HMAC für eine Nachricht zu erzeugen, selbst wenn der verwendete Hash-Algorithmus bekannt ist.

Das ist der entscheidende Unterschied zu einem einfachen Hash: Ein gewöhnlicher Hash (MD5, SHA-256 usw.) nimmt nur die Nachricht als Eingabe, sodass ihn jeder berechnen kann und er nichts über den Urheber aussagt. Ein HMAC verwendet die Nachricht *und* einen geheimen Schlüssel, sodass ein gültiger HMAC beweist, dass der Absender das Geheimnis besaß — er ist ein Authentifizierungsmechanismus, nicht nur eine Integritätsprüfung.

HMAC ist formal vom NIST in FIPS 198-1 standardisiert und für Internetprotokolle in IETF RFC 2104 definiert. Dieses Tool berechnet HMACs über die native Web Crypto API deines Browsers (`crypto.subtle.sign` mit dem HMAC-Algorithmus), die RFC 2104 korrekt implementiert, statt auf eine selbst geschriebene JavaScript-Version zu setzen.

Warum sollte man es nutzen?

• Du integrierst den Stripe-Webhook und der Endpoint meldet "signature verification failed" — du fügst denselben Schlüssel und dieselbe Payload hier ein, um zu sehen, ob dein Server HMAC-SHA256 korrekt berechnet, bevor du weiter im Code suchst.
• Du hast gerade die Funktion geschrieben, die ausgehende Anfragen an eine Drittanbieter-API signiert, und willst ihre Ausgabe gegen eine unabhängige Berechnung prüfen, bevor du sie freigibst.
• Ein Kollege hat dir ein gemeinsames Geheimnis für einen Integrationstest gegeben, und du musst die Signatur einer Testanfrage erzeugen, ohne eine Bibliothek zu installieren oder nur dafür ein Skript zu schreiben.
• Du dokumentierst, wie Anfragen an eure interne API signiert werden, und brauchst ein reproduzierbares Beispiel mit Schlüssel, Nachricht und resultierendem HMAC für den Team-Guide.
• Du vermutest, dass dein Backend bei der Token-Signatur SHA-1 statt SHA-256 verwendet, und willst beide Ergebnisse nebeneinander vergleichen, um zu bestätigen, welches mit dem empfangenen übereinstimmt.

Anleitung

1. Gib deinen geheimen Schlüssel in das Feld „Geheimer Schlüssel“ ein.
2. Gib die Nachricht, die du authentifizieren möchtest, in das Feld „Nachricht“ ein.
3. Die Ergebnisse für HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 und HMAC-SHA512 werden sofort generiert (aktiviere „Ausgabe in Großbuchstaben“, falls dein Zielsystem Großbuchstaben erwartet).
4. Klicke auf „Kopieren“ neben dem HMAC, den du benötigst.

Beispiel

Eingabe

Geheimer Schlüssel: key
Nachricht: The quick brown fox jumps over the lazy dog

Ausgabe

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

Dies ist ein veröffentlichter Standard-Testvektor: Mit dem Schlüssel „key“ und genau dieser Nachricht liefern HMAC-SHA256 und HMAC-SHA1 bei jeder korrekten Implementierung immer diese Werte, sodass du die Ausgabe dieses Tools unabhängig überprüfen kannst.

HMAC vs. einfacher Hash: Wann du einen Schlüssel brauchst

Die entscheidende Frage lautet: Musst du beweisen, wer diesen Digest erzeugt hat, oder nur, dass sich der Inhalt nicht verändert hat? Reicht eine öffentliche Prüfsumme aus — etwa um zu prüfen, ob eine heruntergeladene Datei mit der vom Herausgeber angegebenen übereinstimmt, oder um Datensätze zu deduplizieren —, funktioniert ein einfacher Hash, den jeder ohne Schlüssel überprüfen kann. Musst du hingegen belegen, dass der Digest nur von jemandem stammen kann, der ein bestimmtes Geheimnis besitzt — etwa um einen API-Aufrufer zu authentifizieren oder dem Absender eines Webhooks zu vertrauen —, brauchst du HMAC, denn ein einfacher Hash gäbe einem Angreifer ohne Geheimnis dieselbe Möglichkeit, einen gültigen Digest zu fälschen, wie dem echten Absender.

→ Multi-Algorithmus-Hash-Generator · JWT-Decoder · MD5-Generator

Die vier HMAC-Algorithmen im Vergleich

Alle vier verwenden dieselbe HMAC-Konstruktion aus RFC 2104 und unterscheiden sich nur in der zugrunde liegenden Hashfunktion und damit in der Ausgabelänge.

Häufige Anwendungsfälle

• Signieren ausgehender API-Anfragen mit einem gemeinsamen Geheimnis, damit der Server die Identität des Aufrufers prüfen kann.
• Verifizieren eingehender Webhook-Payloads (Stripe-Signature, GitHub X-Hub-Signature-256 und ähnliche Header verwenden alle HMAC-SHA256).
• Erzeugen und Validieren des Signaturteils eines mit HS256/HS384/HS512 signierten JWT.
• Prüfen, ob deine server- oder clientseitige HMAC-Implementierung vor dem Deployment die erwartete Ausgabe liefert.

Häufige Fehler beim Debuggen einer nicht übereinstimmenden HMAC-Signatur

• Das vom Framework neu formatierte JSON statt des exakten rohen Anfragekörpers signieren — die meisten Webhook-Anbieter (auch Stripe) verlangen, die exakt empfangenen Bytes vor jedem Parsing zu signieren, denn schon ein zusätzliches Leerzeichen ändert den resultierenden HMAC.
• Eine andere Textkodierung als UTF-8 auf einer Seite der Integration verwenden — fast alle modernen Bibliotheken nutzen standardmäßig UTF-8, aber ein Altsystem mit Latin-1 erzeugt für denselben sichtbaren Text einen anderen HMAC.
• Eine Ausgabe in Kleinbuchstaben-Hex mit einem erwarteten Wert in Großbuchstaben vergleichen (oder Base64 statt Hex) — der kryptografische Wert ist derselbe, aber ein wörtlicher Stringvergleich scheitert, wenn die Formate nicht exakt übereinstimmen.
• Einen abschließenden Zeilenumbruch übersehen, den der Texteditor beim Einfügen von Schlüssel oder Nachricht automatisch hinzufügt — für das Auge unsichtbar, ändert aber den berechneten HMAC vollständig.

Häufig gestellte Fragen