Ein Datensatz, der seine eigenen Einstellungen trägt

Der Befehl, den du am Ende von Lektion 3 ausgeführt hast, hat bei jedem Lauf andere Bytes ausgegeben. Um ein Passwort nächste Woche zu prüfen, muss der Server dieselben Bytes noch einmal berechnen, und dafür braucht er dasselbe Salt und dieselben n, r und p. Alle vier müssen mit dem Hash gespeichert werden. Diese Lektion speichert sie auf die einfachste Weise, die es gibt: in einer Textzeile.

Eine Textzeile

Ein Passwort-Datensatz (password record) sieht in diesem Kurs so aus. Er ist eine Textzeile; hier ist er nach dem Salt umbrochen, damit er auf die Seite passt:

scrypt$16384$8$1$Iiddrf4ZE7Bp5ctR/ENjYg==$
SedCTnOCi3DaMFK3PxyvJVqZ0Bt9WC7EjAgXnWwxjuQ=

Er hat sechs Teile, verbunden durch $:

• die Bezeichnung scrypt, die sagt, welche Funktion den Datensatz erzeugt hat. Eine spätere Version des Dienstes kann dann eine andere Funktion hinzufügen und alte Datensätze trotzdem von neuen unterscheiden;

• n, r und p als einfache ganze Zahlen: die Kosten, mit denen dieser Datensatz erzeugt wurde;

• das Salt;

• der Hash.

Salt und Hash sind Bytes, und eine Textzeile kann keine beliebigen Bytes aufnehmen. Also kommen sie als Base64 hinein, mit base64.b64encode(...).decode("ascii"). Standard-Base64 verwendet Buchstaben, Ziffern, +, / und = und nie $, also kann das Trennzeichen nicht innerhalb eines Teils vorkommen.

Andere Passwort-Bibliotheken schreiben Datensätze nach demselben Prinzip. Wenn du je einen gespeicherten Wert siehst, der mit $2b$12$ beginnt, ist das ein Datensatz, den ein anderer Passwort-Hash erzeugt hat, bcrypt, mit seinen Kosten im zweiten Teil.

make_record(password, *, n, r, p) baut diese Zeile: mit new_salt() ein neues Salt ziehen, mit hash_password(...) hashen und die sechs Teile zusammensetzen. Ein f-String erledigt das in einer Zeile.

Beachte, was der Datensatz nicht enthält: das Passwort. Alles darin kann man gefahrlos neben einem Benutzernamen speichern. Das Salt ist absichtlich öffentlich, die Einstellungen sind öffentlich, und der Hash ist die Ausgabe der langsamen Funktion. Ein Dieb, der den Datensatz liest, muss raten, und jeder Versuch kostet einen scrypt-Aufruf mit den Einstellungen des Datensatzes.

Verifizieren

verify_password(password, record) geht den umgekehrten Weg.

1. Teile den Datensatz an $. Wenn das nicht sechs Teile ergibt oder der erste Teil nicht scrypt ist, ist der Text kein Datensatz dieser Art, und die Antwort ist False.

2. Dekodiere das Salt und den gespeicherten Hash mit base64.b64decode(...).

3. Hashe das Passwort mit hash_password(...), mit dem Salt und den drei Zahlen aus dem Datensatz. Verwende int(...) für die Zahlen: Sie kommen als Text aus dem Teilen heraus.

4. Vergleiche den neuen Hash mit dem gespeicherten und gib die Antwort zurück.

Schritt 3 hat eine Falle. Die Einstellungen, die du verwenden musst, sind die des Datensatzes, nicht das heutige COST_N. Ein Datensatz, der mit n=4096 erzeugt wurde, lässt sich nur mit n=4096 reproduzieren.

Schritt 4 ist nach dem Tag in signing.py die zweite Stelle in diesem Projekt, an der ein Geheimnis auf einen erwarteten Wert trifft. Also gilt die Regel aus Kapitel 2: Vergleiche die beiden Byte-Strings mit hmac.compare_digest und gib zurück, was es zurückgibt.

Ein Datensatz gilt hier als vertrauenswürdig. Er kommt aus dem eigenen Zustand des Servers, nicht aus einer Anfrage, also verteidigt sich verify_password nicht gegen einen Datensatz mit absurden Zahlen darin. In den Worten von Kapitel 1: Ein Datensatz überquert die Vertrauensgrenze nie nach innen. Das Passwort tut es, bei jeder Anmeldung.

Die Kosten steigen

Hardware wird jedes Jahr schneller, also erhöht ein Dienst seine Kosten von Zeit zu Zeit. Datensätze, die vor der Änderung erzeugt wurden, bleiben bei den alten Kosten. Deshalb stehen die Kosten im Datensatz: Der Dienst kann Datensätze unterschiedlicher Stärke nebeneinander halten und erkennen, welcher welcher ist.

needs_rehash(record, *, n) beantwortet eine Frage: Wurde dieser Datensatz mit niedrigeren Kosten als n erzeugt? Lies das n des Datensatzes aus seinem zweiten Teil und vergleiche. Vergleiche Zahlen, keinen Text:

print("4096" < "16384", 4096 < 16384)

Der Vergleich ist „niedriger als“, nicht „verschieden von“. Ein Datensatz, der stärker ist als die heutige Einstellung, darf nie durch einen schwächeren ersetzt werden.

Einen schwachen Datensatz durch einen frischen zu den heutigen Kosten zu ersetzen nennt man Rehashing, und es hat einen Haken: Um einen Datensatz zu erzeugen, braucht man das Passwort, und der Server hat es nicht. Der einfachste Moment für das Upgrade ist deshalb eine korrekte Anmeldung, wenn der Benutzer das Passwort gerade gesendet hat. Lektion 6 tut das. Ein Dienst, der nicht warten kann, bis sich jeder Benutzer anmeldet, hat einen anderen Weg, den dieser Kurs nennt und nicht baut: Er kann jeden alten Hash sofort in die stärkere Funktion einwickeln und den eingewickelten Datensatz bei der nächsten Anmeldung durch einen sauberen ersetzen.

Deine Aufgabe

Schreib in passwords.py make_record, verify_password und needs_rehash wie oben beschrieben.

Schreib dann einen Angriffstest. Der Angriff ist die Beobachtung aus Lektion 1: In der geleakten Tabelle haben gleiche Digests verraten, dass zwei Benutzer dasselbe Passwort hatten. Schreib in tests/test_attacks.py unter dem Kommentar für Kapitel 3 test_attack_equal_passwords_get_different_records. Erzeuge mit passwords.make_record(...) bei n=16, r=8, p=1 zwei Datensätze für dasselbe Passwort und sichere zu, dass sie sich unterscheiden. Die niedrigen Kosten halten den Test schnell, und genau dafür sind die Kostenparameter da.

Führ die Tests aus:

python -m pytest -q

Der Lauf endet mit 1 failed, 5 passed. Der eine Fehlschlag ist immer noch der Test aus Kapitel 1. Er wird in Lektion 6 grün.

Klicke dann auf Check my work. Ein Datensatz trägt jetzt alles, was nötig ist, um ein Passwort gegen ihn zu prüfen. Die nächste Lektion sieht sich an, was eine Anmeldung verrät, wenn es keinen Datensatz zum Prüfen gibt.