Velocidad de hash con contraseñas aleatorias verdaderas

2

Solo una pregunta teórica:

Si tuviera usuarios ideales, quienes proporcionen contraseñas de 128 bits completamente aleatorias, Y también, invalido todas las contraseñas de menos de 128 bits.

Entonces, ¿seguiría necesitando una función hash lenta para almacenar estas contraseñas?

    
pregunta jrnv 04.05.2014 - 22:15
fuente

3 respuestas

7

Si se pudiera confiar en que los usuarios proporcionen contraseñas verdaderamente aleatorias, no habría necesidad de usar una función hash lenta. Pero no puedes nunca confiar en los usuarios para eso.

    
respondido por el John Deters 04.05.2014 - 22:23
fuente
4

Si los usuarios proporcionaron contraseñas aleatorias con el equivalente de más de 128 bits de entropía que nunca se usan en otros lugares, no hay necesidad de una función hash lenta como bcrypt, scrypt, sha256crypt, sha512crypt o PBKDF. Del mismo modo, no habría necesidad de una sal en el hash.

¿Por qué? La fuerza bruta es simplemente inviable cuando el tiempo esperado es O (2 128 ); por ejemplo, incluso con miles de millones de computadoras que prueban miles de millones de hashes por milisegundo, no podrá hacer fuerza bruta en un hash de entropía de 128 bits en millones de años (precisamente tendría una posibilidad de 1 en 10000 de romperlo). Por supuesto, no hay un método confiable para probar la fortaleza de las contraseñas creadas por el usuario, ya que la entropía depende en gran medida del modelo. Por ejemplo, una contraseña como: Qwertyuiopasdfghjklzxcvbnm aparecerá como 132 bits a pesar de ser el orden de las teclas del teclado y es bastante baja entropía. O si mi contraseña para security.stackexchange.com era https://security.stackexchange.com , la calculadora dice 147 bits de entropía (cuando está extremadamente débil). Por otro lado, si conoce el método de generación de contraseñas, puede calcular de manera confiable la entropía de las contraseñas; por lo tanto, si obliga a todos sus usuarios a aprender una contraseña aleatoria de 128 bits que generó, puede asegurarse de que sus contraseñas sean razonablemente sólidas.

Sin embargo, aún se necesitaría una función hash, ya que nunca deberías almacenar contraseñas en texto plano. Un atacante no debería poder encontrar una lista de contraseñas de texto sin formato en la base de datos de algún otro compromiso (por ejemplo, encontrar una copia de seguridad antigua, inyección de SQL, pérdida de memoria, etc.). Un hash simple (por ejemplo, SHA-2) funcionaría para evitar eso.

    
respondido por el dr jimbob 04.05.2014 - 22:27
fuente
0

Tienes dos aspectos más que deberías tener en cuenta. 1- ¿Es su entrada de usuario 'lo suficientemente aleatoria'?

Por el momento, la fuerza bruta de 128 bits es inviable. ¿Por qué usar una función hash si los bits son aleatorios? 128 bits aleatorios serán más fuertes que la salida hash de los mismos. Dos contraseñas diferentes pueden producir una colisión en una función hash, cuanto más grande sea el espacio para hacer hash, mayor será la probabilidad de colisiones, mientras que una contraseña aleatoria no tendrá este problema.

2- ¿Cómo recordará alguien 128 bits aleatorios? ¿Alguien cambiaría su contraseña de 128 bits aleatorios después de memorizarla?

Parece una molestia en la solución.

    
respondido por el Anton Garcia Dosil 05.05.2014 - 19:54
fuente

Lea otras preguntas en las etiquetas