0 Bit Entropie
Schlüssellänge
Kodierung
HMAC-Signaturschlüssel für HS256, HS384 und HS512, erzeugt in deinem Browser.
Leertaste erzeugt ein neues Secret, C kopiert es. Erzeugt mit crypto.getRandomValues auf deinem Gerät.
Ein mit HS256, HS384 oder HS512 signiertes Token wird mit demselben Secret geprüft, mit dem es signiert wurde. Dieses Secret ist kein Passwort: Niemand tippt es ein, niemand muss es sich merken, und es soll weder lesbar noch aussprechbar sein. Es ist ein Block zufälliger Bytes, der in einer Umgebungsvariablen oder einem Secret-Manager liegt, und seine einzige Aufgabe ist es, unerratbar zu sein.
Die Bytes stammen unmittelbar aus crypto.getRandomValues, dem kryptografisch sicheren Zufallsgenerator des Browsers, und werden anschließend als Hexadezimal oder Base64 ausgegeben. Auf diesem Weg kommt weder ein Zeitstempel noch ein Zähler noch Math.random vor. 256 Bit ergeben 32 zufällige Bytes, 384 Bit ergeben 48 und 512 Bit ergeben 64 — die Länge entspricht dem Hash, den der jeweilige Algorithmus verwendet.
Der Wert wird in deinem Browser erzeugt und bleibt dort. Beim Neuladen verschwindet er.
Mindestens so lang wie die Hash-Ausgabe des signierenden Algorithmus: 32 Byte (256 Bit) für HS256, 48 Byte für HS384, 64 Byte für HS512. HMAC hasht jeden Schlüssel, der länger als die Blockgröße ist, wieder herunter — 200 Byte sind daher nicht nennenswert stärker als 64. Das eigentliche Risiko liegt darin, darunter zu bleiben.
Weder noch. Es sind dieselben Zufallsbytes in zwei Schreibweisen: 32 Byte sind 64 Zeichen in Hex und rund 44 Zeichen in Base64, bei identischer Stärke. Nehmen Sie das Format, das Ihre Bibliothek erwartet. Läuft der Wert durch eine Konfigurationsdatei oder ein Shell-Skript, ist Hex die robustere Schreibweise, weil darin nur 0-9 und a-f vorkommen.
Base64URL ersetzt + und / durch - und _ und lässt die Auffüllzeichen weg, sodass der Wert unmaskiert in eine URL, einen Query-String oder einen Dateinamen passt. Überall sonst genügt normales Base64. JWTs selbst sind Base64URL-kodiert, das betrifft aber das Token und nicht das Secret, mit dem es signiert wird.
Sie können, und genau daran scheitern HMAC-Signaturen am häufigsten. Eine merkbare Phrase trägt deutlich weniger Entropie, als ihre Länge vermuten lässt, und wer ein einziges gültiges Token besitzt, kann Kandidaten offline so schnell durchprobieren, wie es die Hardware hergibt. Dagegen hilft keine Versuchsbegrenzung. Nehmen Sie Zufallsbytes.
In eine Umgebungsvariable, oder in einen Secret-Manager, falls vorhanden. Niemals ins Repository: Ein in git eingechecktes Secret bleibt auch nach dem Löschen in der Historie, und Historien werden geklont, geforkt und gesichert. Ist das einmal passiert, hilft nur der Austausch.
In einem Rhythmus, den Sie tatsächlich einhalten, und sofort bei jedem Verdacht auf Offenlegung. Praktisch steht dem entgegen, dass ein Wechsel alle mit dem alten Secret signierten Tokens ungültig macht. Systeme, die wechseln müssen, ohne alle abzumelden, lassen für eine Übergangszeit zwei Secrets zu: signiert wird mit dem neuen, geprüft gegen beide, danach wird das alte stillgelegt.
Nein. Diese Verfahren sind asymmetrisch: Sie signieren mit einem privaten Schlüssel und prüfen mit dem passenden öffentlichen, benötigt wird also ein Schlüsselpaar und kein gemeinsames Secret. Diese Seite erzeugt symmetrische HMAC-Secrets, wie sie die HS-Familie verwendet. Sind Aussteller und Prüfer verschiedene Parteien, ist meist ohnehin ein asymmetrisches Verfahren richtig.