Generieren Sie HMAC-Signaturen mit unserem HMAC-Generator.
Der Webhook-Vorfall
Stellen Sie sich vor: Sie erhalten einen Webhook von Ihrem Zahlungsanbieter. Die Nachricht sagt "Zahlung erhalten: 500€". Aber woher wissen Sie, dass diese Nachricht wirklich vom Anbieter stammt und nicht manipuliert wurde?
Was ist HMAC?
HMAC (Hash-based Message Authentication Code) kombiniert einen geheimen Schlüssel mit einer kryptografischen Hash-Funktion, um die Authentizität und Integrität einer Nachricht zu überprüfen.
So funktioniert HMAC
Der Sender berechnet HMAC(Nachricht, Geheimnis) und sendet beides. Der Empfänger berechnet dieselbe HMAC mit dem gemeinsamen Geheimnis. Stimmen die Werte überein, ist die Nachricht authentisch und unverändert.
Praktische Anwendungen von HMAC
Webhook-Verifizierung (Stripe, GitHub), API-Authentifizierung, JWT-Signaturen, sichere Cookies und CSRF-Tokens verwenden alle HMAC-basierte Verfahren.
HMAC implementieren
Verwenden Sie SHA-256 als Hash-Algorithmus. Generieren Sie starke, zufällige Geheimnisse (mindestens 256 Bit). Vergleichen Sie MACs mit zeitkonstanten Vergleichsfunktionen, um Timing-Angriffe zu verhindern.
Sicherheitsüberlegungen
Schützen Sie Ihren geheimen Schlüssel wie ein Passwort. Rotieren Sie Schlüssel regelmäßig. Verwenden Sie unterschiedliche Schlüssel für verschiedene Zwecke.
HMAC im Jahr 2026: weiterhin der Standard für Webhooks
HMAC-SHA256 bleibt das Standard-Signierverfahren der meisten Webhook-Ökosysteme: GitHub, Stripe (v1), Twilio und viele andere verifizieren Payloads mit einem HMAC über ein gemeinsames Geheimnis plus einem Zeitfenster gegen Replay-Angriffe.
Neuere Anbieter bieten zusätzlich Ed25519-Signaturen (etwa GitHub und Stripe v2), die asymmetrische Schlüssel nutzen, sodass jeder verifizieren kann, ohne das Signiergeheimnis zu besitzen. Wenn Sie Absender und Empfänger kontrollieren, ist HMAC-SHA256 mit einem 256-Bit-Zufallsschlüssel weiterhin eine starke, einfache Wahl.
Im Browser unterstützt die Web Crypto API mit subtle.sign HMAC, sodass Sie Webhook-artige Payloads clientseitig ohne Bibliothek verifizieren können – vergleichen Sie Signaturen immer in konstanter Zeit und binden Sie einen Zeitstempel in die signierte Nachricht ein, um Replays zu verhindern.
HMAC-Parameter nach RFC 2104 und FIPS 198-1
RFC 2104 und FIPS 198-1 legen fest, wie HMAC gebildet wird. Für HMAC-SHA256 gilt eine Blockgröße von B = 64 Byte und eine Ausgabelänge von L = 32 Byte; eine Signatur hat damit 256 Bit und wird als 64 Hexzeichen ausgegeben.
Vor der Berechnung wird der Schlüssel auf Blockgröße gebracht: Kürzere Schlüssel werden mit Nullbytes aufgefüllt, längere zuerst mit SHA-256 gehasht. Diese beiden Regeln erklären einen Großteil der Fälle, in denen zwei Implementierungen mit demselben Schlüssel unterschiedliche Signaturen erzeugen.
Intern wird der aufgefüllte Schlüssel einmal mit dem Byte 0x36 (ipad) und einmal mit 0x5c (opad) byteweise XOR-verknüpft. Weil beide Konstanten fest sind, muss die Hash-Funktion nach RFC 2104 nicht kollisionsresistent sein; genau darin unterscheidet sich HMAC von einer reinen Hash-Signatur.
- B = 64 Byte: Blockgröße von SHA-256 und Auffüllgrenze für den Schlüssel
- L = 32 Byte: Ausgabelänge, entsprechend 64 Hexzeichen
- Schlüssellänge mindestens 32 Byte aus einer kryptografisch sicheren Zufallsquelle
Signaturen in konstanter Zeit vergleichen
Ein Vergleich mit == bricht beim ersten abweichenden Byte ab und verrät über die Laufzeit, wie viele führende Bytes korrekt waren. Prüfen Sie Signaturen deshalb mit einer Funktion, deren Laufzeit nicht vom Inhalt abhängt, etwa crypto.timingSafeEqual() in Node.js oder hmac.compare_digest() in Python.
crypto.timingSafeEqual() wirft einen RangeError, wenn die beiden Buffer unterschiedlich lang sind. Prüfen Sie die Länge daher zuerst und vergleichen Sie erst danach die Bytes. Hex und Base64 sind zwei Darstellungen derselben Bytes, also dekodieren Sie den empfangenen Wert, bevor Sie vergleichen, und entfernen Sie Präfixe wie sha256= bewusst.
Signiert wird immer die rohe Bytesequenz. Wer den Body vor dem Prüfen parst und neu serialisiert, verändert Leerzeichen und Feldreihenfolge und erhält eine andere Signatur.
- Signatur lokal nachrechnen: openssl dgst -sha256 -hmac "<Schlüssel>" payload.json
- Zeitstempel gegen die Serverzeit prüfen und Nachrichten außerhalb des Toleranzfensters ablehnen, bei Stripe nach 300 Sekunden.
- Gegenprobe mit einer veränderten Payload: Erst wenn Ihr Dienst die Nachricht verwirft, ist der Signaturpfad wirklich angeschlossen.
FAQ
Q.HMAC vs. einfacher Hash?
A.Ein einfacher Hash beweist Integrität (Daten unverändert), aber nicht Authentizität (wer sie sendete). HMAC beweist beides, weil es den geheimen Schlüssel benötigt.
Q.Wie lang sollte der geheime Schlüssel sein?
A.Mindestens 256 Bit (32 Bytes) für SHA-256. Erzeugen Sie ihn mit einem kryptografisch sicheren Zufallsgenerator.
Q.Welchen Hash-Algorithmus sollte ich verwenden?
A.SHA-256: weit verbreitet und als sicher eingestuft. Vermeiden Sie MD5 und SHA-1 wegen bekannter Schwächen.
Q.Wie verhindere ich Replay-Angriffe bei Webhooks?
A.Binden Sie einen Zeitstempel in die signierte Nachricht ein und lehnen Sie Nachrichten außerhalb eines kleinen Zeitfensters (meist 5 Minuten) ab. Anbieter signieren die Payload zusammen mit einem Zeitstempel-Header; prüfen Sie beides und speichern Sie bei strengen Anforderungen kürzlich gesehene Signaturen.
Q.HMAC oder Ed25519 für Webhooks im Jahr 2026?
A.Beides ist gut: HMAC-SHA256 mit gemeinsamem Geheimnis ist die einfachste und häufigste Wahl, Ed25519 ist besser, wenn der Prüfer das Signiergeheimnis nicht besitzen soll. Anbieter bieten zunehmend Ed25519 an (etwa GitHub und Stripe v2), aber HMAC bleibt ein unterstützter, sicherer Standard.
Referenzen
- RFC 2104 – HMAC: Keyed-Hashing for Message Authentication: https://www.rfc-editor.org/rfc/rfc2104
- NIST FIPS 198-1 – The Keyed-Hash Message Authentication Code (HMAC): https://csrc.nist.gov/pubs/fips/198-1/final
HMAC-Signaturen erstellen
Erzeugen Sie HMAC-SHA256-, SHA-1- oder MD5-Signaturen lokal – Ihr Geheimnis bleibt auf Ihrem Gerät.
Fazit
HMAC macht aus einem gemeinsamen Geheimnis überprüfbare Authentizität. Erstellen und testen Sie Signaturen lokal mit dem HMAC-Generator.
Verwandte Artikel
Dateiintegrität mit SHA-256 prüfen
Prüfen Sie Dateiintegrität mit SHA-256-Checksummen, ohne Dateien auf einen Server hochzuladen. Schritt für Schritt für Browser, Linux, macOS und Windows – inklusive signierter Checksummen.
AES-256-GCM lokal entschlüsseln
AES-256-GCM zu entschlüsseln ist einfach, wenn Sie das Passwort und die richtigen Metadaten haben. Hier ist der genaue Ablauf – und die Fehler, die die Entschlüsselung scheitern lassen.
bcrypt vs. Argon2: Hashing im Vergleich
bcrypt schützt Passwörter seit Jahrzehnten; Argon2 ist die moderne, speicherharte Empfehlung. Hier ist der Vergleich und wann Sie welches Verfahren im Jahr 2026 nutzen sollten.
QR-Code-Druck: Größe, Kontrast, Material
Ein QR-Code, der auf Papier nicht scannt, ist ein kaputter Link. Bringen Sie Mindestgröße, Kontrast, Fehlerkorrektur und Ruhezone in Ordnung, bevor die Datei in den Druck geht.
Entwickler-Sicherheitstools: Zero-Knowledge
Werkzeuge, die Sie für sensible Daten nutzen, sollten diese Daten nicht sehen. Ein Leitfaden zur Zero-Knowledge-Toolbox: was jedes Werkzeug tut, wann es passt und wie Sie es prüfen.
.env-Dateien vor dem Commit verschlüsseln: Ein Praxisleitfaden
Eine .env im Klartext zu committen leakt jedes Secret in Ihrem Repository. Muss eine Kopie in Git liegen, verschlüsseln Sie sie zuerst – so geht der sichere Ablauf.