Al hashear contraseñas, ¿está bien usar la contraseña hash como el salt

Si dos usuarios tienen la misma contraseña, entonces la sal será la misma, lo que resultará en el mismo hash para ambos. Esto es indeseable, porque filtra información acerca de las contraseñas. Si Alice ingresa en su base de datos y ve que Bob tiene el mismo hash que ella, puede usar esa información. Elija algo que esté garantizado para ser único.

tu mayor problema aquí es que estás usando hash sin ninguna información sobre qué es el hash. Dependiendo del sistema, incluso podría ser la antigua implementación de 3DES de mierda que elimina todo después del octavo carácter. Debe utilizar un KDF adecuado, como bcrypt o PBKDF2.

Para responder a esto, uno tiene que entender por qué las sales son necesarias en primer lugar. Esto se explica bastante bien en ¿Cómo hash seguro las contraseñas? ; Aquí hay un extracto de la respuesta aceptada:

Sales : entre las ventajas del atacante sobre el defensor, está el paralelismo . El atacante usualmente toma una lista completa de contraseñas con hash, y está interesado en romper la mayor cantidad posible de ellas. Puede intentar atacar a varios paralelos. Por ejemplo, el atacante puede considerar una contraseña potencial, codificarla y luego comparar el valor con 100 contraseñas cifradas; esto significa que el atacante comparte el costo del hashing sobre varias contraseñas atacadas. Una optimización similar es tablas precomputadas , incluidas tablas de arco iris ; esto sigue siendo un paralelismo, con un cambio de coordenadas de espacio-tiempo.

La característica común de todos los ataques que utilizan el paralelismo es que funcionan con varias contraseñas que se procesaron con la función de hash exacta . Salting se trata de usar no la función hash one , sino muchas funciones hash distintas ; idealmente, cada instancia de hash de contraseña debería usar su propia función hash. Un salt es una forma de seleccionar una función hash específica entre una gran familia de funciones hash. Las sales aplicadas correctamente frustrarán completamente los ataques paralelos (incluidas las tablas de arco iris).

Entonces, el problema de su sal es que no interfiere con la paralelización rompiendo los hashes, que es el propósito de la salazón. Le recomiendo encarecidamente que lea la respuesta original , tiene más consejos sobre la salazón.

Si usa la contraseña como "sal", entonces no está usando sal en absoluto; simplemente hashsh la contraseña.

Si dos usuarios eligen la misma contraseña, terminan con la misma contraseña hash. Eso es lo que a menudo se dice como si explicara el problema, pero parece que la mayoría de las personas se equivocan. Imaginan que esto significa "colisión", lo cual, por alguna razón, es considerado por muchos como una mala palabra cuando se habla de hashing de contraseñas. Pero eso es incorrecto, y no el punto.

El punto es determinismo . Supongamos que, indiscriminadamente, tomo una copia de las contraseñas de hash para 1000 usuarios (por ejemplo, recuperé una cinta de copia de seguridad antigua de su contenedor de basura). Luego puedo "probar" las contraseñas potenciales: padezco una contraseña potencial (usando la contraseña misma como "sal") y luego busco el valor entre los 1000 valores hash. Esto significa que al pagar el precio computacional de un hashing, realmente trato de mil usuarios + contraseñas por contraseña. Estoy atacando mil contraseñas de hash en paralelo, por el mismo costo que atacar a una sola. Este tipo de paralelismo puede expresarse bajo varias formas, incluidas las tablas de arco iris.

Realmente lo preferimos cuando atacar 1000 contraseñas de hash cuesta 1000 veces el costo de atacar 1 contraseña de hash. Para hacer eso, necesita sales reales, es decir, sales que son distintas para usuarios distintos, incluso cuando usan la misma contraseña, y, en realidad, cuando potencialmente usan la misma contraseña. Cuando no hay sal real, el ataque paralelo funciona no porque algunos usuarios elijan la misma contraseña, sino porque si hubieran elegido la misma contraseña entonces habrían obtenido el mismo valor hash. Realmente no necesitan elegir la misma contraseña para desencadenar la debilidad.

Usar el nombre de usuario como sal es mucho mejor. No es bueno, fíjate; pero aun mejor Lo que es aún mejor, hasta el punto de ser realmente decente, es usar sales aleatorias.

Utilizar un nombre de usuario o contraseña como un salt no me parece una buena idea.

Un atacante podría suponer razonablemente que estás usando el nombre de usuario o la contraseña como sal. Dependiendo de su configuración, puede ser muy razonable asumir que un atacante podría obtener acceso a los nombres de usuario.

También dependiendo de qué tan estricto sea su sistema para hacer cumplir las contraseñas, el atacante podría aprovechar las contraseñas que aparecen en un diccionario de contraseñas conocidas / comunes, y como éstas se usan como la sal que su sistema sería vulnerable a este tipo de ataque .

Utilizar una sal que no se base en las opiniones del usuario es una idea mucho mejor.

Recientemente se han producido casos en los que se han filtrado más de 100,000,000 hashes. Esperemos que fueran salados. Creo que un gran número como este hace que el efecto de la salazón sea mucho más obvio.

Digamos que hay contraseñas que no son realmente inseguras, pero no lo suficientemente seguras, porque la posibilidad de que un usuario aleatorio use una de estas contraseñas es una en 10 billones. Si intento solo 100 contraseñas de este tipo, entonces puedo esperar adivinar la contraseña de uno de estos 100 millones de personas. Debido a que la contraseña estaba oculta, luego se mezclaba con el hash y otra vez, puedo averiguar fácilmente qué se almacena en la base de datos para cada una de estas contraseñas, así que después de 100 hashes encontré una contraseña.

Si las contraseñas estaban correctamente saladas, cada una con una sal diferente, incluso si se conoce cada sal, tengo que calcular 10 mil millones de hashes para obtener el mismo resultado.