HMAC-Generator und Signaturprüfer

Was dieses Werkzeug tut

HMAC macht aus einer Nachricht und einem gemeinsamen Geheimnis eine kurze Signatur. Wer dasselbe Geheimnis hat, kann sie nachrechnen und sehen, ob die Nachricht unverändert ankam und von jemandem stammt, der das Geheimnis ebenfalls kennt. Dieses Werkzeug berechnet alle vier gängigen Varianten auf einmal und sagt Ihnen zu einer zugesandten Signatur, welche davon sie erzeugt hat.

Diese zweite Richtung ist meist der Grund, weshalb man hier landet. Ein Webhook scheitert an der Prüfung, und die eigentliche Frage lautet nicht „ist diese Signatur gültig“, sondern „welche der mehreren plausiblen Sachen mache ich anders als der Absender“.

Am Schlüssel geht es schief

HMAC signiert Bytes mit Bytes. Die Nachricht liegt meist auf der Hand — der rohe Anfragerumpf —, der Schlüssel fast nie, denn ein Geheimnis kommt als Zeichenkette an, und eine Zeichenkette ist erst dann Bytes, wenn Sie entschieden haben, wie sie zu lesen ist:

a3f2  ->  61 33 66 32   4 bytes   als Text
a3f2  ->  a3 f2         2 bytes   als Hex

Beide Lesarten sind legitim, beide ergeben eine völlig wohlgeformte Signatur, und die beiden Signaturen haben nichts gemeinsam. Nichts warnt Sie: kein Fehler, keine Beschwerde über die Länge, nur ein Wert, der nicht zu dem passt, den der Absender berechnet hat. Deshalb ist die Schlüsselkodierung hier eine sichtbare Wahl statt einer Vermutung — wenn eine Signatur nicht passt, ist das das Erste, was man umschaltet.

Als grobe Orientierung: ein Geheimnis mit einem Präfix wie whsec_ oder eine Folge aus Groß- und Kleinbuchstaben und Ziffern ist normalerweise als Text gemeint; eine Zeichenkette aus genau 32 oder 64 Zeichen, die nur 0-9 und a-f verwendet, ist meist Hex; und eine, die auf = endet, ist fast sicher Base64. Prüfen Sie aber die Dokumentation des Absenders statt der Form, denn die Form ist kein Beweis.

Die Nachricht muss genau die richtigen Bytes sein

Die andere Hälfte einer Abweichung ist die Nachricht. HMAC ist über Bytes definiert, also ändert alles, was die Bytes ändert, die Signatur vollständig — es gibt keine Teilpunkte und kein Beinahe.

• JSON neu serialisieren. Einen Rumpf zu parsen und wieder auszugeben kann Schlüssel umsortieren, Leerzeichen ändern oder Zahlen normalisieren. Signieren und prüfen Sie den rohen Rumpf, den Sie erhalten haben, nie eine hin- und zurückgewandelte Kopie.
• Ein abschließender Zeilenumbruch. Manche Werkzeuge fügen einen hinzu, wenn man den Rumpf in eine Datei speichert; er ist ein Byte, und er ändert alles.
• Die Zeichenkodierung. Ein Rumpf mit Nicht-ASCII-Text muss auf beiden Seiten in derselben Kodierung gelesen werden — in der Praxis UTF-8.
• Kompression oder Middleware. Wenn etwas vor Ihrem Handler den Rumpf entpackt oder umschreibt, prüfen Sie davor, nicht danach.

Viele Anbieter signieren zudem nicht den Rumpf allein. Stripe signiert einen Zeitstempel und den Rumpf, verbunden durch einen Punkt; AWS signiert eine kanonische Anfrage aus Methode, Pfad, Headern und einem Hash der Nutzlast. Scheitert die Prüfung gegen den blanken Rumpf, ist die signierte Zeichenkette vermutlich nicht der blanke Rumpf — das steht in der Dokumentation des Absenders und lohnt sich, bevor man weiter sucht.

Warum SHA-1 hier angeboten wird und im Hash-Werkzeug nicht

Das Hash-Werkzeug markiert SHA-1 als gebrochen. Dieses führt HMAC-SHA-1 ohne Warnung, und das ist Absicht, kein Versehen.

Für Signaturen und Zertifikate ist SHA-1 unbrauchbar, weil sich Kollisionen konstruieren lassen: Man kann zwei verschiedene Dokumente dazu bringen, denselben Digest zu haben. HMAC hängt nicht von dieser Eigenschaft ab. Seine Sicherheit ruht auf dem geheimen Schlüssel, und die Konstruktion — die Nachricht zweimal zu hashen, den Schlüssel beide Male eingemischt — hält auch dann, wenn der zugrunde liegende Hash kollisionsschwach ist. HMAC-SHA-1 bleibt solide und ist das, was OAuth 1.0a und ältere AWS-Signierung verwenden; ein Werkzeug, das die Berechnung verweigerte, wäre also schlicht weniger nützlich, ohne sicherer zu sein.

Für Neues ist SHA-256 die vernünftige Wahl. Längere Digests sind hier nicht nennenswert stärker — die Sicherheitsgrenze ist der Schlüssel, nicht die Digest-Länge —, also lohnen SHA-384 und SHA-512 nur, wenn etwas, mit dem Sie zusammenarbeiten müssen, sie verlangt.

Signaturen sicher vergleichen

Diese Seite vergleicht mit einem gewöhnlichen Zeichenkettenvergleich, und das ist hier in Ordnung: Sie halten den Schlüssel selbst, es gibt nichts zu verraten. In einem Server, der eine eingehende Anfrage prüft, ist es nicht in Ordnung. Ein gewöhnlicher Vergleich hält beim ersten abweichenden Byte an, sodass die benötigte Zeit verrät, wie viel einer Rateversion stimmte, und wer viele Anfragen senden kann, kann eine gültige Signatur Byte für Byte rekonstruieren.

Nehmen Sie den Vergleich in konstanter Zeit, den Ihre Plattform bietet — crypto.timingSafeEqual in Node, hmac.compare_digest in Python, hash_equals in PHP — auf den rohen Bytes statt auf Hex-Zeichenketten. Dazu: vergleichen Sie gegen eine selbst berechnete Signatur, statt einem in der Anfrage genannten Algorithmus zu vertrauen, und weisen Sie eine Nachricht zurück, deren Zeitstempel weit von jetzt entfernt ist, damit eine alte gültige Signatur nicht wiedereingespielt werden kann.

HMAC ist weder ein Hash noch eine Signatur

Hier werden drei Dinge verwechselt, und der Unterschied zählt für das, was man hinterher behaupten kann:

• Ein Hash nimmt eine Nachricht und liefert einen Digest. Jeder kann ihn berechnen, er belegt also, dass sich die Nachricht nicht versehentlich geändert hat — nicht, dass sie von jemand Bestimmtem kommt.
• Ein HMAC nimmt eine Nachricht und ein gemeinsames Geheimnis. Beide Seiten haben denselben Schlüssel, er belegt also, dass der Absender das Geheimnis kannte. Welche Seite gesendet hat, kann er nicht belegen, denn beide hätten ihn erzeugen können.
• Eine Signatur nutzt einen privaten Schlüssel, den nur der Absender hat, und einen öffentlichen, mit dem jeder prüfen kann. Das ergibt die Nichtabstreitbarkeit: Der Absender kann sie später nicht leugnen.

HMAC ist damit das richtige Werkzeug zwischen zwei Systemen, die bereits ein Geheimnis teilen — Webhooks, interne APIs, Sitzungstoken — und das falsche, wenn man einem Dritten beweisen muss, wer etwas gesendet hat. Beachten Sie außerdem: Es authentifiziert, verbirgt aber nichts. Die Nachricht reist im Klartext, und HMAC sagt nichts über Vertraulichkeit.