Was eine HMAC-Signatur tatsächlich beweist
HMAC kombiniert eine kryptografische Hashfunktion wie SHA-256 mit einem geheimen Schlüssel. Der Sender berechnet daraus eine Signatur, der Empfänger wiederholt die Berechnung. Stimmen beide Werte überein, wurde die signierte Nachricht seit dem Versand nicht verändert und sie stammt von einer Partei, die den gemeinsamen Schlüssel kennt. Vertraulichkeit liefert HMAC nicht – TLS bleibt deshalb Pflicht.
- Integrität der signierten Daten
- Authentizität des sendenden Systems
- Keine Verschlüsselung des Inhalts
Eine eindeutige Nachricht signieren
Die Sicherheit steht und fällt mit der Zeichenfolge, die in die Signatur eingeht. HTTP-Methode, Pfad, Zeitstempel, Nonce und ein Hash des unveränderten Request-Bodys sollten in einer exakt definierten Reihenfolge zusammengeführt werden. Beide Seiten müssen dieselbe Kodierung, Trennzeichen und Normalisierung verwenden. Bei Webhooks wird deshalb idealerweise der rohe Body vor jeder JSON-Transformation geprüft.
- Methode und Pfad binden
- Zeitstempel und Nonce einbeziehen
- Rohen Payload-Hash signieren
Replay-Angriffe wirksam begrenzen
Eine gültige Signatur kann kopiert und erneut gesendet werden. Ein enger Zeitkorridor begrenzt die Lebensdauer eines Requests; eine eindeutige Nonce oder Event-ID verhindert die wiederholte Verarbeitung innerhalb dieses Fensters. Der Empfänger prüft daher zuerst den Zeitstempel, verwirft bereits bekannte IDs und validiert erst dann die Signatur.
Verifikation ohne Nebenkanäle und Fehlertoleranz
Signaturen werden dekodiert und mit einer konstantzeitlichen Vergleichsfunktion geprüft, damit Laufzeitunterschiede keine Informationen preisgeben. Fehlende Header, unbekannte Schlüssel-IDs, zu alte Zeitstempel und ungültige Kodierungen müssen geschlossen scheitern. Erst nach erfolgreicher Prüfung darf die Anwendung den Request fachlich verarbeiten oder dauerhaft quittieren.
- Konstantzeitlich vergleichen
- Bei jedem Prüfungsfehler ablehnen
- Vor der Geschäftslogik verifizieren
Schlüsselrotation gehört zum Design
HMAC-Secrets gehören in einen Secret Manager, niemals in Quellcode, Logs oder Client-Anwendungen. Eine Key-ID ermöglicht kontrollierte Rotation: Während eines kurzen Übergangs akzeptiert der Empfänger den alten und den neuen Schlüssel, danach wird der alte konsequent deaktiviert. Metriken zu fehlgeschlagenen Prüfungen und Replay-Versuchen machen Angriffe und Integrationsfehler früh sichtbar.
- Secrets serverseitig verwalten
- Rotation über Key-IDs vorbereiten
- Prüffehler beobachten und alarmieren