Wie kann bcrypt eingebaute Salze haben?

In Coda Hales Artikel "So speichern Sie ein Passwort sicher" heißt es:

In bcrypt sind Salze eingebaut, um Regenbogentischangriffe zu verhindern.

Er zitiert dieses Papier , das besagt, dass in der OpenBSD-Implementierung von bcrypt:

OpenBSD generiert das 128-Bit-bcrypt-Salt aus einem arcfour-Schlüsselstrom (arc4random (3)), der mit zufälligen Daten versehen ist, die der Kernel aus Geräte-Timings sammelt.

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

• Es muss für jedes gespeicherte Passwort unterschiedlich sein, damit für jedes eine separate Regenbogentabelle generiert werden muss
• Es muss irgendwo gespeichert werden, damit es wiederholbar ist: Wenn ein Benutzer versucht, sich anzumelden, versuchen wir es mit seinem Kennwort, wiederholen den gleichen Salt-and-Hash-Vorgang wie bei der ursprünglichen Speicherung seines Kennworts und vergleichen

Wenn ich Devise (einen Rails-Anmeldemanager) mit bcrypt verwende, befindet sich keine Salzspalte in der Datenbank, daher bin ich verwirrt. Wenn das Salz zufällig ist und nirgendwo gelagert wird, wie können wir den Hashing-Prozess zuverlässig wiederholen?

Kurz gesagt, wie kann bcrypt eingebaute Salze haben ?

Das ist bcrypt:

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

Leiten Sie einen Verschlüsselungsschlüssel aus dem Kennwort unter Verwendung des Salz- und Kostenfaktors ab. Verwenden Sie diese Option, um eine bekannte Zeichenfolge zu verschlüsseln. Speichern Sie die Kosten, das Salz und den Chiffretext. Da diese drei Elemente eine bekannte Länge haben, ist es einfach, sie zu verketten und in einem einzigen Feld zu speichern, sie jedoch später aufzuteilen.

Wenn jemand versucht, sich zu authentifizieren, rufen Sie die gespeicherten Kosten und das gespeicherte Salz ab. Leiten Sie einen Schlüssel aus dem eingegebenen Passwort, den Kosten und dem Salz ab. Verschlüsseln Sie dieselbe bekannte Zeichenfolge. Wenn der generierte Chiffretext mit dem gespeicherten Chiffretext übereinstimmt, stimmt das Kennwort überein.

Bcrypt funktioniert sehr ähnlich wie herkömmliche Schemata, die auf Algorithmen wie PBKDF2 basieren. Der Hauptunterschied besteht in der Verwendung eines abgeleiteten Schlüssels zum Verschlüsseln von bekanntem Klartext. Andere Schemata gehen (vernünftigerweise) davon aus, dass die Schlüsselableitungsfunktion irreversibel ist, und speichern den abgeleiteten Schlüssel direkt.

In der Datenbank gespeichert, könnte ein bcrypt"Hash" ungefähr so ​​aussehen:

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

Dies sind eigentlich drei Felder, die durch "$" begrenzt sind:

• 2aIdentifiziert die verwendete bcryptAlgorithmusversion.
• 10ist der Kostenfaktor; 2 ¹⁰ Iterationen der Schlüsselableitungsfunktion werden verwendet (was übrigens nicht ausreicht. Ich würde Kosten von 12 oder mehr empfehlen.)
• vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTaist das Salz und der Chiffretext, verkettet und in einer modifizierten Base-64 codiert. Die ersten 22 Zeichen werden auf einen 16-Byte-Wert für das Salt dekodiert. Die verbleibenden Zeichen sind Chiffretext, der zur Authentifizierung verglichen werden soll.

Dieses Beispiel stammt aus der Dokumentation zur Ruby-Implementierung von Coda Hale.

Ich glaube, dieser Satz hätte wie folgt formuliert werden müssen:

In bcrypt sind Salze in die generierten Hashes eingebaut , um Regenbogentischangriffe zu verhindern.

Das bcryptDienstprogramm selbst scheint keine Liste von Salzen zu führen. Vielmehr werden Salze zufällig generiert und an die Ausgabe der Funktion angehängt, damit sie später gespeichert werden (gemäß der Java-Implementierung vonbcrypt ). Anders ausgedrückt, der von erzeugte "Hash" bcryptist nicht nur der Hash. Es ist vielmehr der Hasch und das Salz verkettet.

Um die Dinge noch klarer zu machen,

Registrierungs- / Login-Richtung ->

Das Passwort + Salt wird mit einem Schlüssel verschlüsselt, der aus den Kosten, Salt und dem Passwort generiert wird. Wir nennen diesen verschlüsselten Wert den cipher text. Dann hängen wir das Salt an diesen Wert an und codieren ihn mit base64. Anhängen der Kosten daran und dies ist die produzierte Zeichenfolge aus bcrypt:

$2a$COST$BASE64

Dieser Wert wird schließlich gespeichert.

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

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

Was wichtiger ist: In diesem Prozess gibt es kein Hashing, sondern eine CPU-teure Verschlüsselung - Entschlüsselung. Daher sind Regenbogentabellen hier weniger relevant.

Dies stammt aus der PasswordEncoder-Schnittstellendokumentation von Spring Security.

 * @param rawPassword the raw password to encode and match
 * @param encodedPassword the encoded password from storage to compare with
 * @return true if the raw password, after encoding, matches the encoded password from
 * storage
 */
boolean matches(CharSequence rawPassword, String encodedPassword);

Das heißt, man muss rawPassword abgleichen, das der Benutzer bei der nächsten Anmeldung erneut eingibt, und es mit dem Bcrypt-codierten Passwort abgleichen, das während der vorherigen Anmeldung / Registrierung in der Datenbank gespeichert wurde.