Einen Anwendungs-Geheimschlüssel richtig erzeugen

Erste Frage: welche Zufallsquelle

Jede Sprache hat zwei Zufallszahlengeneratoren, und sie sind nicht austauschbar. Der eine ist schnell, aus einem Startwert deterministisch und für das Mischen einer Playlist oder das Streuen eines erneuten Versuchs gedacht. Der andere ist langsamer, schöpft aus dem Entropievorrat des Betriebssystems und ist für alles gedacht, was ein Angreifer gern erraten würde. In JavaScript sind das Math.random und crypto.getRandomValues; in Python random und secrets; in PHP mt_rand und random_bytes. Den ersten dort zu nehmen, wo der zweite hingehört, ist der häufigste Fehler eines Schlüsselgenerators.

Was Math.random disqualifiziert, ist nicht, dass die Ausgabe gemustert aussähe — tut sie nicht. Es ist, dass der Generator eine kleine deterministische Maschine mit rekonstruierbarem Zustand ist. V8, die Engine in Chrome und Node, verwendet xorshift128+, einen 128-Bit-Zustand, der durch Schiebungen und Exklusiv-Oder fortgeschrieben wird. Aus einer kurzen Folge aufeinanderfolgender Ausgaben lässt sich dieser Zustand rekonstruieren, und danach ist jeder künftige Wert bekannt und jeder vergangene nachspielbar. Die Engine ist auch nicht verpflichtet, ihn unvorhersehbar zu initialisieren, und Browser haben ihn historisch aus Dingen initialisiert, die ein Angreifer beobachten oder beeinflussen kann.

Dieses Werkzeug ruft den richtigen auf. Liest man den Code vom Knopf nach innen: Der Erzeugungs-Handler baut eine Zeichenkette Zeichen für Zeichen mit randStr, randStr wählt jeden Index mit rngInt, und rngInt legt ein Uint32Array mit einem Element an und füllt es mit crypto.getRandomValues. Es gibt einen Rückfall auf Math.random, aber er steht hinter einer Prüfung auf das Vorhandensein von crypto und crypto.getRandomValues, und getRandomValues ist in jedem Browsing-Kontext verfügbar, auch in unsicheren — anders als crypto.subtle. In der Praxis ist der Rückfall unerreichbarer Code.

Zweite Frage: wie viele Bit, und wie man sie selbst zählt

Die Rechnung passt in eine Zeile. Wird jedes Zeichen unabhängig und gleichverteilt aus einem Alphabet von n Zeichen gezogen, trägt jedes Zeichen log2(n) Bit, und ein Schlüssel der Länge L trägt L × log2(n). Das ist alles. Es gibt keinen Zuschlag für „enthält Sonderzeichen“ oder „sieht kompliziert aus“: Alphabetgröße und Länge sind die einzigen Eingaben, weshalb ein langer Kleinbuchstaben-Schlüssel einen kurzen voller Satzzeichen schlägt.

Wende sie auf die Voreinstellung an. Der Django-Zeichensatz besteht aus den sechsundzwanzig Kleinbuchstaben, den zehn Ziffern und den vierzehn Zeichen !@#$%^&*(-_=+) — fünfzig insgesamt, ohne Doppelung, was zählt, weil ein wiederholtes Zeichen das wirksame Alphabet stillschweigend verkleinern würde. log2(50) sind 5,644 Bit je Zeichen, der voreingestellte 50-Zeichen-Schlüssel trägt also 282,2 Bit. Die alphanumerische Option hebt das Alphabet auf zweiundsechzig und den Schlüssel auf 297,7 Bit; die volle Option auf sechsundsiebzig und 312,4 Bit. Alle drei sind riesig neben den 128 Bit, die üblicherweise als ausreichend genannt werden — dreiundzwanzig Zeichen des Django-Satzes würden sie schon überschreiten.

Die WordPress-Seite misst sich genauso. Sie gibt die acht wp-config-Konstanten aus — die vier Schlüssel und die vier Salts — mit je 64 Zeichen aus einem 92-Zeichen-Satz: die zweiundsechzig Buchstaben und Ziffern, dann !@#$%^&*() und schließlich -_ []{}<>~`+=,.;:/?|. Das ist Zeichen für Zeichen das, was WordPress' eigenes wp_generate_password mit beiden Sonderzeichen-Argumenten liefert, und 64 × log2(92) ergibt 417,5 Bit je Konstante. Zwei Einzelheiten dieses Satzes lohnen den Blick: Er enthält ein Leerzeichen, was zulässig und leicht überraschend ist, und er enthält weder einfaches Anführungszeichen noch Backslash — deshalb landet der erzeugte Wert ohne jedes Escaping in define('AUTH_KEY', '…');.

Der Modulo-Bias, ehrlich benannt

Es gibt einen Mangel in der Umsetzung, und er gehört genau benannt, denn eine vage Formulierung wäre alarmierender als der Mangel selbst. Um eine zufällige 32-Bit-Zahl in einen Index in ein 50-Zeichen-Alphabet zu verwandeln, nimmt der Code den Rest: Index gleich Wert modulo 50. Zwei hoch zweiunddreißig ist 4 294 967 296, und das lässt sich nicht durch fünfzig teilen. Der Rest ist sechsundvierzig, also lassen sich sechsundvierzig der fünfzig Zeichen aus 85 899 346 der möglichen Werte erzeugen und die anderen vier aus 85 899 345.

Die bevorzugten Zeichen sind also um ein Verhältnis von eins zu 85 899 345 wahrscheinlicher als die übrigen, etwa 1,2 zu hundert Millionen. Für den 92-Zeichen-Satz von WordPress ist der Rest zwölf und das Verhältnis etwa 2,1 zu hundert Millionen. Ein Generator, der das behöbe, nutzte Rückweisungsstichproben — neu ziehen, sobald der Wert in den ausgefransten Schwanz fällt — und gewänne einen Unterschied, den keine Messung an einem 50-Zeichen-Schlüssel je feststellen könnte. Das ist eine Fußnote, keine Warnung.

Der Bias verschwindet vollständig, wenn die Alphabetgröße eine Zweierpotenz ist, denn dann geht die Division auf — ein Alphabet mit 64 Zeichen oder 256 Werten hat gar keinen. Das ist der elegante Grund, warum ein Großteil des Schlüsselmaterials in Hexadezimal oder Base64 ausgedrückt wird: Die Arithmetik ist exakt, und es bleibt nichts zu diskutieren.

Wozu der Schlüssel dient, und was ein Wechsel deshalb zerstört

Djangos Dokumentation zählt genau auf, was von SECRET_KEY abhängt: jede Sitzung, außer man nutzt das Cache-Sitzungs-Backend und hat den voreingestellten Session-Auth-Hash überschrieben; jede in einem Cookie gespeicherte Nachricht; jeden Token zum Zurücksetzen des Passworts; und jede Nutzung des Signatur-Frameworks, die keinen eigenen Schlüssel übergibt. Die Folge steht auf derselben Seite: Sobald ein Schlüssel nicht mehr SECRET_KEY ist und nicht in SECRET_KEY_FALLBACKS steht, wird all das auf einen Schlag ungültig.

In der Praxis heißt das: Alle sind ausgeloggt und jeder Zurücksetzen-Link, der schon in einem Postfach liegt, funktioniert nicht mehr — genau das, was man nach einem Leck will, und genau das, was man an einem Dienstagnachmittag grundlos nicht will. SECRET_KEY_FALLBACKS ist der dokumentierte Weg, beides zu haben: den neuen Schlüssel in SECRET_KEY setzen, den alten lange genug in der Fallback-Liste behalten, bis laufende Sitzungen und Links verfallen sind, und ihn dann entfernen. Django sagt ausdrücklich, dass Benutzerpasswörter nicht aus dem Schlüssel abgeleitet werden und in keinem Fall betroffen sind.

WordPress bietet keine vergleichbare Schonfrist, und seine eigene Dokumentation sagt es in einem Satz: Man kann die Schlüssel jederzeit ändern, um alle bestehenden Cookies ungültig zu machen, und das heißt, dass sich jede Nutzerin neu anmelden muss. Es gibt keine Fallback-Liste; die Änderung ist sofort und vollständig. Dieselbe Seite merkt an, dass die vier Schlüssel erforderlich und die vier Salts nur empfohlen sind, weil WordPress Salts selbst erzeugt, wenn keine definiert sind — ein Grund mehr, alle acht einzufügen statt der Hälfte.

Wo ein gut erzeugter Schlüssel trotzdem verbrennt

Der Generator ist der leichte Teil. Fast jeder echte Vorfall beginnt danach. Ein Schlüssel landet in einer eingecheckten Konfigurationsdatei, in einem in ein Ticket eingefügten Screenshot, in einer Nachricht an eine Kollegin, in einem Build-Log, in einer Umgebungsvariablen, die ein Debug-Endpunkt ausgibt, oder in einer Container-Image-Schicht, die den Branch überlebt, aus dem sie stammt. Nichts davon ist ein kryptografisches Versagen; alles davon beendet die Brauchbarkeit des Schlüssels genauso vollständig.

Der Fall Versionskontrolle verdient einen eigenen Satz, weil der Instinkt falsch ist. Die Zeile zu löschen und die Löschung zu committen entfernt den Schlüssel nicht: Er steht weiter in der Historie, weiter in jedem gemachten Klon und weiter in jedem Fork und jedem Spiegel des Repositorys. Die Historie umzuschreiben hilft nur, wenn du zugleich jede bereits geholte Kopie ungültig machst, was du nicht kannst. Die einzig solide Antwort ist, den Schlüssel als öffentlich zu betrachten und zu wechseln.

Im Browser zu erzeugen ist völlig in Ordnung und besser, als es klingt. Der Schlüssel entsteht in der Seite, die du schon offen hast, aus der Zufälligkeit des Betriebssystems selbst, und er existiert nur in diesem Tab, bis du ihn kopierst. Nichts wird irgendwohin geschickt, weil nichts geschickt werden muss: fünfzig Indizes zu ziehen und fünfzig Zeichen zusammenzufügen sind ein paar Zeilen Code, und ein Server fügte nur einen weiteren, nicht einsehbaren Ort hinzu, an dem der Schlüssel existiert hätte.

Häufige Fragen

Ist ein im Browser erzeugter Schlüssel so sicher wie einer vom Server?

Eher sicherer. crypto.getRandomValues schöpft aus derselben Betriebssystem-Entropie, die ein Server nutzen würde, die Zufälligkeit hat also dieselbe Güte. Der Unterschied ist der Weg des Schlüssels: In der Seite erzeugt, existiert er in einem Tab und geht nirgendwohin, bis du ihn kopierst, während ein serverseitiger Generator bedeutet, dass der Schlüssel auf einer Maschine existierte, die du nicht kontrollierst, in einem Prozess, den du nicht einsehen kannst, vielleicht in einer Logzeile, die du nie zu Gesicht bekommst. Lade die Seite neu oder schließe den Tab, und der Wert ist fort. Wovor ein Browser dich nicht schützen kann, ist die Zwischenablage und das, wohin du danach einfügst.

Wie lang muss ein Geheimschlüssel wirklich sein?

Nimm die Voreinstellung des Frameworks und denke nicht weiter darüber nach. Djangos eigene Funktion liefert 50 Zeichen, aus ihrem 50er-Alphabet also 282 Bit; WordPress gibt 64 Zeichen aus 92 aus, also 418. Die üblich genannte Schwelle für ein symmetrisches Geheimnis liegt bei etwa 128 Bit, und 23 Zeichen des Django-Alphabets überschreiten sie bereits. Die Mehrlänge kostet nichts und bringt nichts; die Einstellungen mit 80 oder 100 Zeichen gibt es der Vollständigkeit halber, nicht weil sie jemand braucht. Die Länge wird erst dann zum falschen Hebel, wenn das Alphabet winzig ist: ein 20-Zeichen-Schlüssel aus reinen Ziffern trägt 66 Bit, weniger als die Hälfte eines 20-Zeichen-Schlüssels aus dem Django-Satz.

Heißt der Modulo-Bias, dass ich diesen Generator nicht nutzen sollte?

Nein. Der Bias ist echt und beträgt beim Django-Alphabet 1,2 zu hundert Millionen: Sechsundvierzig der fünfzig Zeichen sind aus 85 899 346 der vier Milliarden möglichen 32-Bit-Werte erreichbar, die anderen vier aus 85 899 345. Über fünfzig unabhängige Ziehungen verteilt, verschiebt er die Entropie eines Schlüssels um eine Größe weit unterhalb jeder Einheit, die man drucken würde. Wofür der Bias wirklich taugt, ist als Merkmal beim Lesen fremder Generatoren: Ein nackter Rest sagt dir, dass niemand an Rückweisungsstichproben gedacht hat — ein Hinweis auf den restlichen Code —, und Rückweisungsstichproben sagen dir, dass jemand daran gedacht hat. Keines von beidem ist ein Grund, einen bereits 282 Bit tiefen Schlüssel abzulehnen.

Was geht in dem Moment kaputt, in dem ich den Schlüssel wechsle?

In Django: jede Sitzung, die nicht im Cache-Backend liegt, jede in einem Cookie gespeicherte Nachricht und jeder Token zum Zurücksetzen des Passworts, samt der Links, die schon in Postfächern liegen. Die Dokumentation sagt es klar und nennt die Abmilderung — den alten Schlüssel in SECRET_KEY_FALLBACKS verschieben, ihn lange genug dort lassen, bis laufende Sitzungen und Links von selbst verfallen, dann löschen. Benutzerpasswörter werden nicht aus dem Schlüssel abgeleitet und bleiben unberührt. In WordPress gibt es keine Fallback-Liste: Das Ändern einer der acht Konstanten macht jedes bestehende Cookie sofort ungültig, und die Dokumentation sagt wörtlich, dass sich alle Nutzer neu anmelden müssen. Plane einen Schlüsselwechsel für eine ruhige Stunde — außer du reagierst auf ein Leck, dann tu es jetzt und nimm die Abmeldungen hin.

Ich habe meinen Schlüssel nach git committet. Reicht es, die Zeile zu löschen?

Nein. Ein Commit, der eine Zeile löscht, lässt den vorigen Commit unangetastet, der Schlüssel steht also weiter in der Historie und weiter in jedem bestehenden Klon, Fork und Spiegel. Die Historie umzuschreiben entfernt ihn aus deiner Kopie und bei allen, die danach holen, aber nicht bei denen, die vorher geholt haben — und bei einem öffentlichen Repository muss man annehmen, dass dazu automatische Scanner gehören, die neue Commits genau darauf beobachten. Betrachte den Schlüssel als veröffentlicht: Erzeuge einen neuen, lege den alten in die Fallback-Liste, falls dein Framework eine hat, und entferne ihn nach dem Übergangsfenster. Mach das Leck danach strukturell unmöglich, indem du den Wert in einer Umgebungsvariablen oder einem Secret-Store hältst und nur eine Datei committest, die die Variable benennt.