So erzeugst du einen HMAC
Gib gemeinsames Geheimnis und Nachricht genau nach Protokoll ein, wähle SHA-2 und Ausgabeform. Schon ein Leerzeichen, Zeilenumbruch oder eine andere Schlüsselkodierung erzeugt einen anderen Code.
- Füge den Schlüssel nur dann wörtlich ein, wenn das Protokoll UTF-8-Text verlangt; Hex oder Base64 steht oft für Bytes, die zuerst dekodiert werden müssen.
- Füge die exakten Daten einschließlich Zeilenenden, Trennzeichen, Zeitstempel und Kanonisierung ein.
- Wähle HMAC-SHA-256, -384 oder -512 und Hex oder Base64 entsprechend dem Vertrag.
- Berechne und vergleiche den vollständigen Code; leere danach Schlüssel und Zwischenablage.
Beispiele und erwartetes Verhalten
| Eingabe | Ausgabe | Hinweise |
|---|---|---|
Schlüssel Jefe
Daten what do ya want for nothing?
HMAC-SHA-256 |
5bdcc146bf60754e6a042426089575c75… |
RFC-4231-Testvektor, Fall 2. |
Schlüssel secret
Daten message |
Deterministischer HMAC |
Gleiche Bytes, Algorithmus und Kodierung liefern denselben Wert. |
Schlüssel secret
Daten Message |
Anderer HMAC |
Groß-/Kleinschreibung ändert die Nachrichtenbytes. |
Schlüssel geheim
Daten Hallo 👋 |
UTF-8-HMAC |
Internationale Zeichen werden als UTF-8 kodiert. |
Hex-Ausgabe |
Zwei Zeichen pro Byte |
HMAC-SHA-256 hat 64 Hexzeichen. |
Base64-Ausgabe |
Base64 derselben Bytes |
Die Darstellung ändert nicht den kryptografischen Wert. |
Was HMAC bietet
HMAC kombiniert eine geheime Schlüsselbytefolge mit einer kryptografischen Hashfunktion. Wer denselben Schlüssel besitzt, kann den Code reproduzieren und Änderungen erkennen; Dritte ohne Schlüssel sollen keine veränderte Nachricht authentisieren können.
HMAC liefert Integrität und gemeinsame Authentizität, aber keine Verschlüsselung. Die Nachricht bleibt lesbar und es gibt keine Nichtabstreitbarkeit, weil alle Schlüsselinhaber gültige Codes erzeugen können.
- HMAC-SHA-256 verwendet SHA-256 in der HMAC-Konstruktion.
- Taglänge entspricht dem zugrunde liegenden Hash.
- Vertraulichkeit braucht separate Verschlüsselung.
Schlüsseldarstellung und -verwaltung
Das Feld interpretiert den Schlüssel als UTF-8-Text. Eine Hex- oder Base64-Zeichenfolge stellt in Protokollen häufig rohe Schlüsselbytes dar; ihre sichtbaren Zeichen wörtlich zu hashen ergibt einen anderen HMAC. Dekodiere nach Spezifikation.
Sicherheit hängt von Entropie, Speicherung, Rotation und Zugriff ab. Nutze zufällige Schlüssel, Secret-Manager, minimale Rechte, Key-IDs und Widerruf. Lege Geheimnisse nicht in Repositories, Tickets oder gemeinsam genutzte Notizen.
- Rohbytes und kodierten Text unterscheiden.
- Keine menschlichen Passwörter direkt als HMAC-Schlüssel.
- Rotation für Webhooks planen.
Kanonische Bytes und UTF-8
HMAC authentisiert Bytes. Zeilenende, Leerraum, Unicode-Normalisierung, JSON-Reihenfolge, URL-Kodierung oder Zeitstempelformat ändern den Wert. JSON vor der Verifikation neu zu formatieren bricht üblicherweise die Signatur.
Verwende den rohen Body oder exakt die definierte Signing-String-Konstruktion. Füge Separatoren und führende Nullen korrekt ein und ändere Sekunden nicht eigenmächtig in Millisekunden.
- CRLF und LF sind verschieden.
- Ein abschließender Umbruch zählt.
- Visuell gleiche Unicode-Zeichen können andere Bytes haben.
Algorithmus und Ausgabekodierung
Unterstützt werden HMAC-SHA-256, -384 und -512. Verwende genau den geforderten Algorithmus. SHA-256 ist verbreitet, doch neue Protokolle sollten einem geprüften Standard folgen.
Hex und Standard-Base64 stellen dieselben Tagbytes dar. Standard-Base64 ist nicht Base64url. Alphabet, Padding und Hex-Schreibweise müssen exakt zum Protokoll passen.
- HMAC-SHA-256 erzeugt 32 Bytes.
- Hex-Großschreibung kann vertraglich relevant sein.
- Standard-Base64 nutzt +, / und oft =.
Webhook- und API-Verifikation
Ein robuster Verifier liest den rohen Request-Body, extrahiert Zeit und Key-ID, baut die definierte Nachricht, berechnet HMAC und vergleicht zeitkonstant. Zusätzlich prüft er Frische und Replay.
Diese Seite ist für Testvektoren und Diagnose, nicht als Endpoint. Verwende Produktionsgeheimnisse nicht auf gemeinsam genutzten Geräten und verifiziere serverseitig vor jeder privilegierten Aktion.
- Rohbytes verwenden, wenn verlangt.
- Alte Zeitstempel ablehnen.
- Zeitkonstant vergleichen.
- Bei Rotation Schlüssel über Key-ID wählen.
Fehler, Grenzen und sicherer Umgang
Ein leerer Schlüssel wird abgelehnt und Web Crypto ist erforderlich. Schlüssel und Nachricht bleiben nur im Seitenzustand ohne absichtliche Persistenz. Das Leeren löscht keine Zwischenablagehistorie, Erweiterungen oder Bildschirmaufzeichnungen.
Akzeptiert wird Text, nicht rohe Binärschlüssel oder Dateien. Das Werkzeug leitet keine Schlüssel ab, kürzt keine Tags, vergleicht nicht und verwaltet keinen Replay-Zustand. Für hochsensible Geheimnisse ist eine auditierte lokale Umgebung vorzuziehen.
- Keine echten Produktionsgeheimnisse in gemeinsamem Browser.
- Zwischenablage nach Gebrauch leeren.
- Tags nur nach expliziter Spezifikation kürzen.
Abgrenzung zu Hash und Verschlüsselung
Ein einfacher Hash besitzt keinen Schlüssel. HMAC ist eine standardisierte Konstruktion und sollte nicht durch hash(key || message) ersetzt werden, das strukturelle Schwächen besitzen kann.
Verschlüsselung verbirgt Inhalt; HMAC authentisiert ihn, verbirgt ihn aber nicht. Wenn beides nötig ist, verwende ein geprüftes authentifiziertes Verschlüsselungsverfahren.