Zum Inhalt springen
L

Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

Is Your Password Actually Stored? Sites Keep a Salted Hash

KNOW TECH 9:44 145 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

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

Zum Nachlesen

Salt (Kryptologie)Salt (englisch für Salz) bezeichnet in der Kryptographie eine zufällig gewählte Zeichenfolge, die an einen gegebenen Klartext vor dessen weiterer Verarbeitung ( … Rainbow TableJede dieser Ketten startet mit einem initialen Kennwort, welches durch eine Hashfunktion geleitet wird. Der resultierende Hash wird wiederum durch eine … SchlüsselableitungDie gebräuchlichste Verwendung von Schlüsselableitungsfunktionen ist der Passwort-Hash bei der Passwortverifizierung. Schlüsselableitungsfunktionen weisen … Challenge-Response-AuthentifizierungAlice ergänzt diese Zahl N um ihr Passwort, wendet eine kryptologische Hashfunktion oder Verschlüsselung auf diese Kombination an und sendet das Ergebnis an Bob …