Intentando entender el hashing de contraseñas

  

Luego se probó que md5 tuvo colisiones, por lo que las personas comenzaron a cambiarse a SHA1 y así sucesivamente.

Tenga en cuenta que no se requiere resistencia a la colisión para el hashing de la contraseña. Todavía no hay razón para usar un hash más débil de lo necesario.

  

¿Por qué no se puede usar SHA512 en un algoritmo de contraseña si lo iteramos lo suficiente para crearlo lentamente? Ejemplo es SHA512 la contraseña 100k veces.

Puedes hacer eso. Siempre que mezcle contraseña y sal al principio, debe ser seguro.

No lo recomendamos, porque no hay razón para inventar su propio esquema, cuando hay muchos esquemas estándar.

  

¿Por qué se recomienda PBKDF2 o bcrypt en lugar de hacer lo anterior? ¿O por qué no lo es?

Porque están estandarizados y han sido vistos por muchos criptógrafos. Por lo tanto, puede estar más seguro de que no hay puntos débiles en el esquema que en su esquema ad hoc.

PBKDF2 es esencialmente una función hash iterada, que utiliza HMAC para mezclar la contraseña y el salt.

bcrypt es una construcción diferente. Es un poco más difícil romper ese PBKDF2, ya que requiere un poco más de memoria (unos pocos kB), lo que aumenta un poco la cantidad de puertas requeridas.

También hay un esquema llamado scrypt que tiene un parámetro de memoria ajustable, lo que le permite hacer que el esquema consuma cantidades significativas de memoria (varios megabytes o más). Esto evita que el hardware especial sea mucho más eficiente que el hardware estándar, ya que aún necesitan comprar mucha memoria RAM.
Scrypt es probablemente el más fuerte de estos esquemas. Pero es relativamente nuevo y utiliza primitivas poco comunes, por lo que muchos usuarios aún escogen esquemas más antiguos.

  

Esta respuesta indica que no es "para hash una contraseña para el almacenamiento seguro con fines de autenticación". Sin embargo, esta respuesta (con muchos votos positivos) recomienda lo contrario

Esa pregunta es sobre una recomendación explícita de NIST para PBKDF2 con hashing de contraseña. Solo hay una recomendación de usar PBKDF2 para la obtención de claves basada en contraseña, una técnica estrechamente relacionada. La ausencia de una recomendación NIST no implica que el esquema sea malo.

  

Si una función PBKDF2 se basa en SHA1 debajo, ¿es inherentemente insegura si se puede demostrar que SHA1 está roto?

Si hay un primer ataque de pre-imagen contra SHA1, que funciona bajo ciertas restricciones, entonces sí, PBKDF2 con SHA1 está roto. Un ataque de colisión por otro lado no es suficiente. Un primer ataque de pre-imagen suele ser mucho más difícil que un ataque de colisión. Por ejemplo, ni siquiera sabemos uno contra MD5.

  

¿Por qué no se puede usar SHA512 en un algoritmo de contraseña si lo iteramos lo suficiente para crearlo lentamente? El ejemplo es SHA512 la contraseña 100k veces.

No hay ninguna razón por la que esto no pueda funcionar. Esto es lo que esencialmente es PBKDF2.

  

¿Por qué se recomienda PBKDF2 o bcrypt en lugar de hacer lo anterior? ¿O por qué no?

PBKDF2 básicamente toma un hash SHA y lo repite varias veces.

bcrypt por otro lado, utiliza el algoritmo de pez globo y requiere más acceso a la memoria para realizar, lo que no es muy eficiente en una GPU. Esto hace que sea más difícil para un atacante con una GPU acelerar el proceso de craqueo. Esto es lo mismo que scrypt, por extensión.

  

Si una función PBKDF2 se basa en SHA1 debajo, ¿es inherentemente insegura si se puede demostrar que SHA1 está roto?

Desde mi entendimiento, sí.

La razón por la que la gente sugiere el uso de funciones derivadas clave para el hashing es que el tiempo necesario para descifrar el hash de la contraseña se puede aumentar simplemente elevando el número de iteraciones. Esto hace que sea más fácil mantener los hashes seguros a medida que el hardware se vuelve cada vez más poderoso sin cambiar el algoritmo de hashing.

La implementación de bcrypt no es muy compleja ya que hay muchas bibliotecas fáciles de usar que hacen el trabajo por usted. Por ejemplo: phpass para perl, php y python.

No soy exactamente un experto en criptografía, así que toma mi respuesta con un grano de sal. Sin embargo, este parece ser el consenso general de los expertos de lo que he leído.

Con respecto al primer enlace , creo que su respuesta fue solo a la pregunta, no hay un requisito oficial de NIST para usar PBKDF2 para las contraseñas de hashing. Aún así es mejor que un simple hash SHA.

1. La iteración no siempre aumenta el tiempo para romperlo debido a la escalabilidad del hardware lineal.

2. Porque bcrypt hace que los decodificadores de hardware sean más lentos.

3. Pero ese es el punto de hacer PKBF, a múltiples iteraciones, haciéndolo más lento de esta manera, sin embargo bcrypt es más fuerte.