Is Your Password Actually Stored? Sites Keep a Salted Hash
KNOW TECH 
https://www.youtube.com/watch?v=K08kdbWGuxI

Transkript (automatisch erstellt)

0:00 Eine Login-Tabellenzeile ist auf dem Bildschirm zu sehen. Email, salt, algorithm,
0:06 cost, hash. Die Passwortspalte fehlt. Man würde erwarten, dass die Seite das speichert,
0:13 was sie prüft, aber die sicherste Zeile weigert sich, es zu behalten. Wie kann eine Website also beweisen,
0:19 dass du ein Passwort kennst, ohne das Passwort selbst zu speichern?
0:23 Die kurze Antwort ist auf genau die richtige Weise unbequem. Eine verantwortungsvolle Seite speichert einen verifier,
0:31 einen salted hash, der einen künftigen Versuch bestätigen kann, aber das ursprüngliche Passwort nicht preisgeben sollte.
0:38 Wenn du Passwörter wiederverwendest, entscheidet diese fehlende Spalte, ob eine gestohlene database
0:43 nur eine Reset-Email wird oder ein Schlüssel zu deiner Bank, deinem Postfach
0:47 und deinem cloud account. Früher dachte ich, die Geschichte sei encryption.
0:52 Ist sie nicht. Die Antwort ist kein vault. Sie ist eine wiederholbare Berechnung mit einer absichtlich
0:59 teuren falschen Antwort. Das ist diese Episode von KNOW:
1:04 TECH. Die normale Annahme klingt plausibel. Eine Seite fragt nach deinem Passwort.
1:21 Sie sagt yes oder no. Irgendwo
1:25 stellt sich dein Gehirn ein verstecktes Regal vor, in dem dieses Passwort wartet.
1:29 Aber ein gutes Login-System sollte sich nicht so an dich erinnern.
1:33 Es sollte sich an Belege erinnern, die du neu erzeugen kannst. NIST P800-63B verwendet das Wort verifier,
1:42 und dieses Wort ist wichtig. Das Gespeicherte ist meist ein hash plus
1:48 metadata, salt, algorithm, version und ein work factor oder memory cost.
1:54 Ein hash ist eine Einwegtür. Du kannst ein Passwort hindurchschieben und
1:59 bekommst ein Ergebnis, das fest aussieht. Du solltest das Passwort nicht wieder
2:02 herausholen können. Beim Login nimmt das System deinen neuen Versuch,
2:07 fügt den gespeicherten salt hinzu, führt dieselben settings aus
2:11 und vergleicht das neue Ergebnis mit dem gespeicherten proof. Ich will bei den Vergleichen kurz langsamer machen.
2:17 Es entschlüsselt das alte Passwort nicht. Es stellt es nicht wieder her.
2:22 Es fragt, ob die heutige Berechnung auf dem gestrigen proof landet. Das macht die Passwort-database nützlich für
2:29 den Login-Server und nutzlos für alle, die hoffen, dass sie Passwörter enthält.
2:34 Aber wenn ein hash eine Einbahnstraße ist, warum sind gestohlene Passwort-databases dann immer noch wichtig?
2:40 Stell einen salt shaker neben die Zeile. Das Bild ist einfach,
2:43 aber die Aufgabe ist präzise. Ein salt ist zusätzliche zufällige data, gemischt in
2:48 das Passwort jedes users vor dem hashing. Hier ist der Teil, der mich überrascht hat.
2:54 Der salt wird normalerweise neben dem hash gespeichert. Er ist kein secret key.
3:00 Es klingt, als müsste er versteckt sein, aber Verstecken ist nicht seine Hauptaufgabe.
3:05 Ohne salts kann dasselbe Passwort denselben hash über viele accounts hinweg erzeugen.
3:11 Angreifer können lookup tables für gängige Passwörter vorberechnen und diese Arbeit wiederverwenden.
3:17 Mit einem unique salt wird dasselbe Passwort in jeder Zeile zu einem anderen
3:21 target. Der breach wird also nicht an der Tür gestoppt.
3:25 Er wird bei jedem guess verlangsamt. OWASPs password storage cheat sheet wird konkret, wenn
3:32 Argon2ID verfügbar ist. Es empfiehlt mindestens 19 mebibytes an memory,
3:38 zwei iterations und einen Grad an parallelism. Das klingt nach tuning trivia, bis man sich vorstellt,
3:44 dass der Angreifer die ganze Tabelle hat. Normales Login muss erträglich bleiben.
3:50 Das Cracking gestohlener Datenbanken, muss teuer werden.
3:54 Ich sehe das als den Preis eines guess. Sobald man das erkennt,
3:58 wirken alte breach stories nicht mehr wie eine Kategorie namens password leak.
4:03 Die timeline beginnt am 5. Juni 2012, als der LinkedIn password hash breach
4:08 öffentlich wurde. Have I Been Pwned listet 164 Millionen offengelegte email addresses und passwords,
4:16 wobei passwords als unsalted SHA-1 hashes gespeichert waren. SHA-1 ist schnell,
4:23 und schnell ist genau das, was man nicht will, nachdem die database gestohlen wurde.
4:28 Ich sage das nicht, um auf ein einzelnes company einzuschlagen. Viele ältere systems wurden gebaut, als der
4:33 login server wie der bottleneck wirkte. Nach dem Diebstahl bringt der attacker den bottleneck nach Hause.
4:39 Dann kommt Dropbox. Have I Been Pwned verbindet den breach vom 1. August
4:44 2012 mit mehr als 68 Millionen records, die email addresses und salted password hashes enthielten,
4:51 aufgeteilt zwischen SHA-1 und Bcrypt. Diese Aufteilung ist wichtig.
4:57 Zwei Menschen im selben incident konnten unterschiedlichem cracking pressure ausgesetzt sein, weil ihre rows unterschiedliche
5:02 schemes nutzten. Dann, am 3. Oktober 2013, gab Adobe bekannt, dass attackers auf customer IDs
5:10 und encrypted passwords zugegriffen hatten. Encryption hat gute Einsatzbereiche,
5:14 aber recoverable password storage hat einen scharfen failure mode. Wenn das system das password
5:20 zurückholen kann, kann jemand, der die richtigen pieces kompromittiert, es vielleicht ebenfalls tun.
5:26 Hier hat sich mein model verändert. Die login table row ist nicht nur storage.
5:32 Sie ist eine Wette darauf, was der thief als Nächstes tun kann.
5:35 Die sicherste password database ist eine, die dir das password nicht nennen kann.
5:41 Jetzt schauen wir auf einen anderen screen. Pwned passwords. Das Problem ist heikel.
5:47 Man will prüfen, ob ein password in bekannten breaches aufgetaucht ist,
5:51 aber das ganze password an einen service zu senden, würde genau das risk erzeugen, das man reduzieren will.
5:56 Troy Hunts Pwned Passwords range API löst das mit einem k-anonymity prefix.
6:03 Der client hasht das password mit SHA1, sendet nur die ersten fünf Zeichen dieses hash,
6:08 und bekommt passende suffixes mit counts zurück. Der service kann bei der Prüfung helfen, ohne das ganze secret
6:14 zu empfangen. Dieser fünfstellige prefix ist die interface-Version
6:19 der fehlenden Spalte. Er fragt nach gerade genug evidence,
6:23 nicht nach allem. Aber das ist keine Magie.
6:27 Der prefix schützt den lookup. Er macht ein schwaches password nicht stark.
6:32 Wenn das password häufig ist, kann der zurückgegebene count genau zeigen, warum
6:36 das login system es ablehnen sollte. Ich kam immer wieder auf dieselbe enge
6:41 Frage zurück. Wenn das system das password nicht wiederherstellen kann, woher weiß es dann trotzdem, dass man das
6:47 richtige eingegeben hat? Die Antwort ist kleiner als memory und stärker als trust.
6:54 Es führt den test erneut aus. RFC 9106, datiert auf 2021,
7:01 standardisierte Argon2 für password hashing use, und sagt, dass Argon2 ID von
7:08 Implementierungen dieses RFC unterstützt werden muss. Die wichtige Formulierung lautet:
7:13 memory hard. In einfachem Englisch: Die function lässt attackers mit memory bandwidth
7:20 und hardware capacity bezahlen, nicht nur mit CPU speed.
7:24 Jetzt setzen wir das in ein launch review. Product will, dass sign-up reibungslos bleibt.
7:30 Operations will eine vorhersehbare Serverlast. Security will, dass die gestohlene Tabelle enttäuschende
7:37 Beute ist. Jemand zeigt auf die Login-Zeilen und fragt: Zeigt mir die gezählte Arbeit.
7:44 Saubere Zeile, unique salt, argon2id, memory cost aufgezeichnet,
7:49 hash gespeichert, kein plaintext password. Saubere Zeile, bcrypt für einen älteren Account beibehalten,
7:58 Version für die Migration markiert, keine Passwortspalte.
8:03 Umstrittene Zeile, unsalted SHA1 weil ein legacy service noch davon abhängt.
8:10 Umstrittene Zeile, encrypted password, weil ein Support-Workflow Wiederherstellung will.
8:17 Das ist die Drucksituation, kein Lock-Icon.
8:22 Ein Tabellen-Review vor einem Launch, bei dem Kompatibilität, Geschwindigkeit
8:26 und Schaden bei einem Breach alle unterschiedliche Antworten verlangen.
8:31 Der salt verhindert, dass 1Password zu einem wiederverwendbaren Lookup wird. Der cost factor macht Raten zu einem
8:38 operativen Aufwand. Eine memory-hard function macht die Hardware des Angreifers zu einem Teil der Verteidigung.
8:46 Login ist Vergleich, nicht Erinnerung. Holt die erste Zeile zurück.
8:51 Email, salt, algorithm, version, cost, memory,
8:57 hash. Immer noch keine Passwortspalte. Was wie fehlende Daten aussah,
9:04 sieht jetzt aus wie Design, das seine Aufgabe erfüllt. Wenn euer Team heute entscheiden müsste,
9:09 Würdet ihr neue Logins auf Argon2ID mit höherem memory cost umstellen?
9:14 Oder bcrypt aus Kompatibilitätsgründen behalten und das Risikobudget in passkeys stecken?
9:21 Erzählt uns in den Kommentaren, was euer eigenes System, eure invoice oder euer incident euch beigebracht hat.
9:27 Dieser Kanal verfolgt die Mechanismen, die entscheiden, ob aus einem Breach eine Schlagzeile wird
9:32 oder ein eingedämmter Ausfall. Danke fürs Zuschauen.
9:36 Bis zum nächsten Mal.