HMAC

Was HMAC zusätzlich zum Hash leistet

Ein gewöhnlicher kryptografischer Hash fingerprinted Daten: jeder kann SHA-256(message) neu berechnen und vergleichen. Ein HMAC (Hash-based Message Authentication Code) mischt vor dem Hashen einen geheimen Schlüssel mit der Nachricht, sodass nur Parteien mit Schlüsselkenntnis den Tag erzeugen oder prüfen können. Das Ergebnis ist ein Digest fester Länge—oft als Hex gezeigt—, der unter dem Shared-Secret-Modell Integrität und Herkunft authentifiziert.

HMAC wird weit für API-Request-Signaturen, Webhook-Verifikation und signierte Cookies genutzt. Es verschlüsselt die Nachricht nicht; für Vertraulichkeit brauchen Sie eine Chiffre oder TLS. Es ersetzt auch keine Public-Key-Signaturen, wenn Parteien keinen gemeinsamen Schlüssel teilen sollten.

Berechnen Sie einen modernen Tag mit HMAC SHA-256 anhand einer Beispielnachricht und eines nur-zum-Testen-Geheimnisses.

Subtools dieser Familie

Der Hub bietet dieselbe HMAC-Konstruktion über drei zugrunde liegende Hash-Funktionen:

• HMAC SHA-256 — bevorzugte Voreinstellung für neue Integrationen; üblich bei AWS-ähnlichem Signing, JWT HS256 und vielen Webhook-Schemata.
• HMAC SHA-1 — noch in älteren APIs anzutreffen; migrieren, wenn Sie beide Enden kontrollieren.
• HMAC MD5 — nur Legacy; nützlich, um alte Checksum-ähnliche MACs zu verstehen, nicht für neue Sicherheitsdesigns.

Wählen Sie das Subtool, das zum Algorithmusnamen im implementierten Protokoll passt. Ein SHA-256-HMAC verifiziert nicht gegen einen MD5-HMAC derselben Nachricht und desselben Schlüssels.

Wie HMAC konstruiert ist (Intuition)

RFC 2104 definiert HMAC grob als Hashen einer Kombination aus Schlüssel und Nachricht mit inneren und äußeren gepaddeten Schlüsselblöcken. Wichtige Engineering-Eigenschaften:

• Der Schlüssel bleibt geheim; der Digest allein sollte ihn nicht verraten.
• Jedes geänderte Bit der Nachricht (oder des Schlüssels) ergibt mit überwältigender Wahrscheinlichkeit einen anderen Tag.
• Verifikation ist Neu-Berechnen-und-Vergleichen—idealerweise in konstanter Zeit für sicherheitskritische Pfade.

Sie müssen das Padding nicht von Hand implementieren, wenn eine Standardbibliotheksfunktion HMAC(hashAlg, key, message) existiert—und in Produktion sollten Sie diese Bibliotheken bevorzugen.

Schlüssel, Nachrichten und Encodings

Schlüsselqualität. Lange, zufällige Schlüssel aus einem CSPRNG verwenden. Menschliche Passphrases sind schwächer, sofern nicht durch ein richtiges KDF geführt. Denselben Schlüssel nicht ohne Domain-Separation für zwei Protokolle verwenden.

Nachrichtenbytes. HMAC authentifiziert exakte Bytes. JSON mit anderer Schlüsselreihenfolge oder Whitespace erzeugt einen anderen Tag, auch wenn die Semantik gleich ist. Strukturierte Daten vor dem Signieren kanonisieren, wenn mehrere Produzenten existieren.

Ausgabe-Encoding. Bibliotheken können Rohbytes, Hex oder Base64 zurückgeben. Zwei Systeme, die Tags vergleichen, müssen Encoding und Hex-Groß-/Kleinschreibung abstimmen. JWT und viele HTTP-Schemata nutzen Base64URL statt Hex—der Spec folgen.

Typische Workflows

Webhook-Verifikation. Ein Anbieter sendet eine Nutzlast plus X-Signature-Header. Ihr Server berechnet HMAC über den Rohkörper mit dem gemeinsamen Geheimnis neu und vergleicht.

API-Request-Signing. Ein kanonischer String (Methode, Pfad, Zeitstempel, Body-Hash) wird von HMAC abgedeckt, damit Intermediäre die Anfrage nicht unbemerkt ändern.

JWT HS256 lernen. Mit HS256 signierte JSON Web Tokens sind HMAC-SHA-256 über base64url(header) + "." + base64url(payload). Siehe auch den JWT-Hub für Encode/Decode/Verify-Flüsse.

MD5, SHA-1 oder SHA-256 wählen

Kollisionsangriffe gegen MD5 und SHA-1 zählen vor allem bei unkeyed Hashing und Zertifikatsmissbrauch. HMAC-MD5 und HMAC-SHA-1 sind in manchen Bedrohungsmodellen stärker als nacktes MD5/SHA-1 für Authentizität, aber moderne Leitlinien steuern neue Designs weiterhin zu HMAC-SHA-256 (oder stärker) für Algorithmus-Agilität und einfache Policy. Bietet ein Vendor nur HMAC-MD5, behandeln Sie das als Kompatibilitätszwang und isolieren Sie die Integration.

Häufige Fehler

• Das Geheimnis in Mobile-Apps oder Frontend-JavaScript zu veröffentlichen und zu erwarten, HMAC beweise dem Server etwas.
• Mit SHA-256 zu hashen, aber den HMAC-Schlüssel-Schritt zu vergessen (oder umgekehrt).
• Einen geparsten und neu stringifizierten Body statt der Roh-Request-Bytes zu signieren.
• Timing-unsichere Stringgleichheit (=== in manchen Kontexten) für Tag-Vergleiche in high-assurance-Code zu nutzen.
• Schlüssel ohne Dual-Verify-Fenster zu rotieren und plötzliche Verifikationsfehler zu verursachen.

Grenzen und Umgebung

Diese Browser-Tools helfen, Digests beim Lernen oder Debuggen zu erzeugen und zu vergleichen. Sie sind kein Key-Management-System. Echte Produktionsgeheimnisse in serverseitigen Stores halten; für Demos Wegwerfschlüssel nutzen.

Zusammenfassung

HMAC macht aus einer Hash-Funktion einen keyed Authenticator. Dieser Hub bietet HMAC-MD5, HMAC-SHA-1 und HMAC-SHA-256, damit Sie Protokollanforderungen treffen und sehen, wie Digests mit Nachricht oder Schlüssel wechseln. Für neue Arbeit SHA-256 bevorzugen, Bytes vor dem Signieren kanonisieren und bedenken: HMAC authentifiziert—es verschlüsselt nicht.