Warum BCrypt.net GenerateSalt (31) zurückkehren sofort?

Question

ich über BCrypt.net stolperte nach dem Lesen Jeff Atwood Beitrag über das Speichern von Passwörtern , die an Thomas Ptacek Empfehlung an Verwendung BCrypt Passwörter zu speichern. Welche führte mich schließlich auf diese C # -Implementierung von BCrypt

In den Kommentaren auf dem letzten Link oben jemand fragt: „Warum GenerateSalt (30) nehmen für immer, aber GenerateSalt (31) scheint überhaupt keine Zeit in Anspruch nehmen?“

Ich lief BCrypt.HashPassword (Passwort, BCrypt.GenerateSalt (31)) und bekam mein Ergebnis in 0 Millisekunden.

Ich habe jetzt BCrypt.HashPassword ( "Passwort", BCrypt.GenerateSalt (30)) für mehr als 5 Minuten gelaufen und habe immer noch kein Ergebnis.

Ich weiß, wir werden wahrscheinlich ein zufällig generierte 30 Zeichen Salz nicht brauchen, um unser Passwort-Hashes zu erstellen (oder irreversible Verschlüsselung in BCrypt Fall ) seit Jahren. Bearbeiten Ich soll den Code ein bisschen gelesen haben, logRounds hat nichts mit der Salz Länge zu tun. Dank Aaronaught.

Also, warum GenerateSalt (31) fast sofort einen Wert zurück (wenn es sollte etwa doppelt so lang wie GenerateSalt (30) nehmen?

UPDATE

Hier ist das Update:

private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
    // ... snip ...
    uint rounds = 1U << logRounds;
    // ... snip
}

Answer 1

Ich vermute, dass der Fehler ist hier:

private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
    // ... snip ...
    int rounds = 1 << logRounds;
    // ... snip
}

Wenn Sie 31 für die logRounds angeben, berechnet sie, dass als 2 ^ 32, die nicht in einem int und überläuft passen, so dass der Hash tatsächlich geschehen ist ... äh, Nulldurchgänge. Der Autor sollte stattdessen verwendet uint hat. Leicht zu reparieren!

---

Auch wollte dazu Stellung:

  

Ich weiß, wir werden wahrscheinlich eine zufällig generierte 30 Zeichen nicht brauchen Salz unser Passwort erstellen Hashes ...

beachten, dass der Parameter logRounds nicht auf die Anzahl der Zeichen bezieht / Bytes in dem Salz, das immer 16. Es bezieht sich auf die logarithmische Basis der Anzahl der Durchgänge, dass der Hash zu berechnen nehmen; mit anderen Worten ist es eine Art und Weise bcrypt Skala mit Moores Gesetz zu machen, um die Funktion mehrere Größenordnungen machen teurer zu berechnen, wenn Computer immer schnell genug, um bestehende Hashes zu knacken.

Answer 2

Wenn mit GenerateSalt(31) Hashing fast sofort zurückkehrt, ist das ein Fehler. Sie sollten diese Upstream-Bericht (ich habe, für jBCrypt). : -)

Standardmäßig werden die Log-Runden ist 10. Das bedeutet, dass (wenn ich mich richtig erinnere), 1024 Runden verwendet wird. Jedes Mal, wenn Sie die Log-Runden erhöhen, wird die Anzahl der Runden verdoppelt.

Bei 30 log-Runden, tun Sie 1073741824 Runden. Das dauert zu Recht eine lange Zeit. Bei 31 log-Runden, 2147483648 Runden getan werden sollte, aber ich vermute, dass die spezielle Implementierung sind Sie überläuft stattdessen verwenden. : - (