¿Por qué BCrypt.net GenerateSalt (31) devuelven enseguida?

Question

me encontré con BCrypt.net después de leer el post Jeff Atwood acerca de almacenar contraseñas lo que me llevó a la recomendación de Thomas Ptacek a uso bcrypt para almacenar contraseñas. Que finalmente me llevó a este C # aplicación de bcrypt

En los comentarios sobre el último enlace de arriba a alguien se le preguntó "¿Por qué GenerateSalt (30) tomar para siempre, pero GenerateSalt (31) parece tener poco tiempo?"

Me encontré BCrypt.HashPassword (contraseña, BCrypt.GenerateSalt (31)) y tengo mi resultado en 0 milisegundos.

He estado corriendo BCrypt.HashPassword ( "contraseña", BCrypt.GenerateSalt (30)) por más de 5 minutos y todavía no tengo un resultado.

Me doy cuenta de que probablemente no necesitaremos una sal de 30 caracteres generada al azar para crear nuestros hashes de contraseñas (o cifrado irreversible en caso de bcrypt) durante años. Editar que debería haber leído el código un poco, logRounds no tiene nada que ver con la longitud de sal. Gracias Aaronaught.

Así que, ¿por qué GenerateSalt (31) devuelve un valor casi al instante (cuando se debe tomar alrededor de dos veces más que GenerateSalt (30)?

Actualizar

aquí es la solución:

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

Answer 1

Sospecho que el error es aquí:

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

Cuando se especifica 31 para el logRounds, se calcula que a medida que 2 ^ 32, que no puede caber en un int y desbordamientos, por lo que el hash que realmente se hace en ... er, cero pases. El autor debe tener uint utiliza en su lugar. Fácil de arreglar!

---

También quería comentar sobre esto:

  

Me doy cuenta de que probablemente no necesitará una generados aleatoriamente 30 caracteres sal para crear nuestra contraseña hashes ...

Tenga en cuenta que el parámetro logRounds no se refiere a la cantidad de caracteres / bytes en la sal, que es siempre 16. Se refiere a la base logarítmica del número de pasadas que el hash se llevará a calcular; en otras palabras, es una manera de hacer bcrypt escala con la Ley de Moore, lo que hace la función de varios órdenes de magnitud más caro para calcular si las computadoras nunca consiguen lo suficientemente rápido como para romper hashes existentes.

Answer 2

Si hash con GenerateSalt(31) vuelve casi al instante, eso es un error. Usted debe informar que aguas arriba (no tengo, por jBCrypt). : -)

Por defecto, el log-rondas es 10. Esto significa que (si no recuerdo mal), se utilizan 1.024 rondas. Cada vez que se incrementa el log-rondas, se duplica el número de rondas.

A los 30 log-rondas, que estás haciendo 1073741824 rondas. Que por derecho le lleva mucho tiempo. A los 31 log-rondas, rondas 2147483648 deben ser hechas, pero sospechan que la implementación particular que está utilizando en su lugar desbordamientos. : - (