Almacenamiento de contraseña hash con sal aleatoria

22

Desde que he creado sitios que requieren que un usuario inicie sesión con un nombre de usuario y contraseña, siempre he mantenido las contraseñas un tanto seguras almacenándolas en mi base de datos con una frase salt. Bueno, recientemente leí que es una mala práctica usar una sola palabra de sal estática. En su lugar, deberías usar una sal aleatoria para cada usuario.

Entiendo que estoy generando una palabra salt aleatoria para cada usuario. Pero mi pregunta es, si tiene que almacenar la sal aleatoria también en su base de datos para poder usarla para hacer una referencia cruzada más adelante para verificar la contraseña ingresada por los usuarios cuando inician sesión. ¿No lo hace tan fácil si los nombres de usuario y Las contraseñas son robadas de su base de datos, ¿entonces no tendrían el mismo acceso a los valores de sal aleatorios? Parece que esa capa adicional de seguridad realmente no agrega mucho a la ecuación.

¿O voy a hacer todo esto mal?

    
pregunta Ryan 20.06.2012 - 23:50
fuente

5 respuestas

18

Añade una cosa significativa. Si roban la base de datos, tienen el nombre de usuario, el sal aleatorio por usuario y la contraseña con hash. Pero todavía no tienen la contraseña original. Para revertir el hash, generalmente tendrán que hacer una cantidad significativa de trabajo por separado para cada usuario.

Sin ninguna sal (una muy mala idea, como aprendió LinkedIn), los atacantes pueden usar preexistente tablas de arco iris y no tienen trabajo por usuario para los hashes que se benefician de las tablas. Incluso si no hay ninguna parte del hash en la tabla, pueden agrupar el trabajo (por ejemplo, si un usuario tiene dos cuentas con la misma contraseña oscura).

Con una sal por sitio, pueden generar una tabla de arco iris para el sitio y seguir compartiendo el trabajo entre los usuarios.

Recuerde que si rompen la contraseña de un usuario, además de poder iniciar sesión en su sitio, es probable que también puedan iniciar sesión en otros sitios que utiliza el usuario.

    
respondido por el Matthew Flaschen 20.06.2012 - 23:54
fuente
9

Lo que hace por ti es que les obliga a generar una tabla de arco iris por usuario en lugar de una tabla de arco iris para que todo el sitio descifre tu contraseña. También significa que no pueden simplemente buscar sus valores de hash en google, que es la "tabla de arco iris definitiva". Cambia la propuesta de craqueo a una tarea mucho más difícil.

Google "5f4dcc3b5aa765d61d8327deb882cf99". Mira lo que obtienes (insinúa que es el hash MD5 de la contraseña y hay miles de resultados).

Hashear cada frase de contraseña con una sal diferente es mejor que usar una sal, pero una sal es mejor que nada de sal.

    
respondido por el hsanders 20.06.2012 - 23:59
fuente
3

El salt es para hacer que el procesamiento de la contraseña sea diferente para cada usuario. De lo contrario, el atacante que obtuvo una copia de su base de datos (usted almacena la contraseña hashes precisamente porque visualiza esta situación) podría optimizar su búsqueda y atacar todas las contraseñas con el mismo esfuerzo que el necesario para romper una contraseña única (las tablas de arco iris, como cualquier otra tabla precomputada, son una encarnación de este concepto). Con las sales por usuario, al menos, el atacante pagará todo el esfuerzo de fuerza bruta por cada contraseña que quiera descifrar.

(Lo ideal es que utilices una sal por usuario que también cambies cada vez que el usuario cambie su contraseña. Por lo tanto, realmente es una sal por contraseña).

Las sales son solo la mitad de la historia; También desea que el mecanismo de hashing sea lento (de una manera configurable, pero muy lento). Un hash simple es demasiado rápido, los atacantes pueden, literalmente, calcular miles de millones por segundo.

Use bcrypt . Las implementaciones de Bcrypt manejan la generación y el uso de sal, y bcrypt se puede hacer tan lento como sea necesario.

    
respondido por el Thomas Pornin 25.11.2012 - 04:05
fuente
2

Las contraseñas con sal individualmente ayudan a prevenir ataques que aprovechan un paso de precálculo fuera de línea, como compensaciones de memoria de tiempo (tablas de raibow). Esto obliga al atacante a forzar con fuerza los hashes para recuperarlos en una contraseña. Esta blog post detalla varias estrategias de almacenamiento de contraseñas, desde la menos segura a la más segura.

    
respondido por el cryptopathe 21.06.2012 - 16:35
fuente
1

Permítame agregar que no desea hacer hash con MD5 o SHA-1. Aquellos fueron diseñados para ser hash rápido. Que es exactamente lo contrario de lo que quieres cuando alguien intenta descifrar tu lista de contraseñas. Hash con bcrypt, que está diseñado para ser lento. Esta es una opción que muchos desarrolladores pasan por alto.

Editar: Aquí hay un buen artículo al respecto.

Editar: Otro artículo dice que PBKDF2 y scrypt también son buenas opciones.

    
respondido por el coding_hero 21.06.2012 - 00:08
fuente

Lea otras preguntas en las etiquetas