Wie kann bcrypt integrierte Salze haben?

Question

Der Artikel von Coda Hale "Wie man ein Passwort sicher speichert" behauptet das:

bcrypt hat Salts eingebaut, um Rainbow-Table-Angriffe zu verhindern.

Er zitiert dieses Papier die besagt, dass in OpenBSDs Implementierung von bcrypt :

OpenBSD generiert das 128-Bit bcrypt-Salz aus einem arcfour (arc4random(3)) Schlüsselstrom, der mit Zufallsdaten geimpft wird, die der Kernel aus den Geräte-Timings sammelt.

Ich verstehe nicht, wie das funktionieren kann. In meiner Vorstellung von einem Salz:

• Sie muss für jedes gespeicherte Passwort unterschiedlich sein, so dass für jedes Passwort eine eigene Regenbogentabelle erstellt werden muss.
• Es muss irgendwo gespeichert werden, damit es wiederholbar ist: Wenn ein Benutzer versucht, sich anzumelden, nehmen wir seinen Passwortversuch, wiederholen dasselbe Salt-and-Hash-Verfahren, das wir bei der ursprünglichen Speicherung des Passworts verwendet haben, und vergleichen

Wenn ich Devise (ein Rails-Login-Manager) mit bcrypt verwende, gibt es keine Salt-Spalte in der Datenbank, also bin ich verwirrt. Wenn das Salz zufällig ist und nirgendwo gespeichert ist, wie können wir den Hashing-Prozess zuverlässig wiederholen?

Kurz gesagt, wie kann bcrypt integrierte Salze haben ?

Answer 1

Dies ist bcrypt:

Erzeugen Sie ein zufälliges Salz. Ein "Kosten"-Faktor wurde vorkonfiguriert. Erfassen Sie ein Passwort.

Ableitung eines Chiffrierschlüssels aus dem Passwort unter Verwendung des Salt und des Kostenfaktors. Verwenden Sie ihn, um eine bekannte Zeichenfolge zu verschlüsseln. Laden Sie die Kosten, Salz, und Chiffretext. Da diese drei Elemente eine bekannte Länge haben, ist es einfach, sie zu verketten und in einem einzigen Feld zu speichern, wobei sie später wieder getrennt werden können.

Wenn jemand versucht, sich zu authentifizieren, werden die gespeicherten Kosten und das Salz abgerufen. Ableitung eines Schlüssels aus dem eingegebenen Passwort, den Kosten und dem Salt. Verschlüsseln Sie die gleiche bekannte Zeichenfolge. Wenn der generierte Chiffriertext mit dem gespeicherten Chiffriertext übereinstimmt, ist das Passwort eine Übereinstimmung.

Bcrypt funktioniert auf sehr ähnliche Weise wie herkömmliche Verfahren, die auf Algorithmen wie PBKDF2 basieren. Der Hauptunterschied besteht in der Verwendung eines abgeleiteten Schlüssels zur Verschlüsselung von bekanntem Klartext; andere Verfahren gehen (vernünftigerweise) davon aus, dass die Funktion der Schlüsselableitung irreversibel ist, und speichern den abgeleiteten Schlüssel direkt.

---

In der Datenbank gespeichert, ist ein bcrypt "Hash" könnte etwa so aussehen:

$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

Es handelt sich eigentlich um drei Felder, die durch "$" voneinander getrennt sind:

• 2a identifiziert die bcrypt die verwendete Algorithmusversion.
• 10 ist der Kostenfaktor; 2 10 Iterationen der Schlüsselableitungsfunktion verwendet werden (was übrigens nicht ausreicht. Ich würde 12 oder mehr Kosten empfehlen).
• vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa ist das Salz und der verschlüsselte Text, verkettet und verschlüsselt in einem modifizierten Base-64. Die ersten 22 Zeichen werden zu einem 16-Byte-Wert für das Salz dekodiert. Die restlichen Zeichen sind der verschlüsselte Text, der zur Authentifizierung verglichen wird.

Dieses Beispiel stammt aus der Dokumentation für die Ruby-Implementierung von Coda Hale.

Answer 2

Meiner Meinung nach hätte dieser Satz wie folgt formuliert werden müssen:

bcrypt hat Salze in die generierten Hashes eingebaut um Regenbogentisch-Angriffe zu verhindern.

Le site bcrypt selbst scheint keine Liste der Salze zu führen. Vielmehr werden die Salze nach dem Zufallsprinzip generiert und an die Ausgabe der Funktion angehängt, so dass sie sich später merken können (gemäß die Java-Implementierung von bcrypt ). Anders ausgedrückt, der "Hash", der von bcrypt じゃない nur die Raute. Vielmehr ist es der Hash y das verkettete Salz.

Answer 3

Dies ist ein einfacher Begriff...

Bcrypt hat keine Datenbank, sondern speichert das Salz...

Das Salz wird dem Hash im base64-Format hinzugefügt....

Die Frage ist, wie bcrypt das Passwort verifiziert, wenn es keine Datenbank hat...?

bcrypt extrahiert das Salt aus dem Passwort-Hash... Verwendet das extrahierte Salt, um das einfache Passwort zu verschlüsseln und vergleicht den neuen Hash mit dem alten Hash, um zu sehen, ob sie gleich sind...

Answer 4

Um die Dinge noch deutlicher zu machen,

Richtung Registrierung/Anmeldung ->

Das Passwort + Salt wird mit einem Schlüssel verschlüsselt, der aus den folgenden Elementen generiert wird: Kosten, Salt und Passwort. cipher text . dann fügen wir das Salz zu diesem Wert hinzu und kodieren es mit base64. wir fügen die Kosten hinzu und dies ist die erzeugte Zeichenkette von bcrypt :

$2a$COST$BASE64

Dieser Wert wird schließlich gespeichert.

Was müsste der Angreifer tun, um das Passwort zu finden? (andere Richtung <- )

Wenn der Angreifer die Kontrolle über die DB erlangt hat, kann er den base64-Wert leicht entschlüsseln und dann das Salz sehen. Das Salz ist nicht geheim, obwohl es zufällig ist. Dann muss er den Salt entschlüsseln. cipher text .

Was noch wichtiger ist: Bei diesem Verfahren wird nicht gehasht, sondern es handelt sich um eine CPU-aufwendige Ver- und Entschlüsselung, so dass Regenbogentabellen hier weniger relevant sind.

Answer 5

Stellen wir uns eine Tabelle vor, die 1 Hash-Passwort enthält. Wenn der Hacker Zugang erhält, würde er den Salt kennen, aber er müsste eine große Liste für alle gängigen Passwörter berechnen und nach jeder Berechnung vergleichen. Das kostet Zeit, und er hätte nur 1 Passwort geknackt.

Stellen Sie sich ein zweites gehacktes Passwort in derselben Tabelle vor. Das Salz ist sichtbar, aber die obige Berechnung muss erneut durchgeführt werden, um auch dieses zu knacken, da die Salze unterschiedlich sind.

Wenn keine zufälligen Salze verwendet worden wären, wäre es viel einfacher gewesen, warum? Wenn wir einfaches Hashing verwenden, können wir Hashes für gängige Passwörter nur ein einziges Mal generieren (Regenbogentabelle) und eine einfache Tabellensuche oder eine einfache Dateisuche zwischen den Hashes der Datenbanktabelle und unseren vorberechneten Hashes durchführen, um die einfachen Passwörter zu finden.