Contraseña de hash con sal [duplicado]

El supuesto es que si el atacante puede obtener el hash (de salt + password), también puede obtener el salt, ya que generalmente se almacenan en la misma ubicación, ya sea en una columna separada en la misma tabla de la base de datos , por ejemplo, o como un solo valor compuesto como puede ver, por ejemplo, de la función * Nix crypt .

Así que sí, el atacante obtendrá el hash y la sal. Esto, sin embargo, no es un problema, ya que no se requiere que la sal sea secreta. Por lo tanto, el hecho de que pueda ser obtenido por el atacante no debilita la seguridad del sistema por debajo de su resistencia diseñada.

1. Obviamente, es preferible evitar el acceso de un atacante a los hashes almacenados. Los hashes son la siguiente línea de defensa después de que falla la denegación de acceso; cuando el atacante vuelca tu base de datos, debe ejecutar un ataque de diccionario en el hash para descubrir el texto plano.

   Lo que evitan las sales es el uso de un "diccionario" precompilado, también conocido como una "tabla de arco iris". Sin una sal, o con una sal de constante universal (la misma cosa), cualquier esfuerzo previo para calcular hashes puede reutilizarse recordando y almacenando el mensaje y su hash, y luego simplemente buscando un hash que coincida. Sin embargo, con una sal aleatoria única para cada valor de hash, ahora no se puede reutilizar ningún trabajo; el mensaje debe incluir ese valor de sal específico, y es extremadamente improbable que un atacante encuentre un mensaje de trabajo en una tabla de arco iris.

2. Sí, el atacante puede obtener la sal. Es información técnicamente "pública", ya que debe estar disponible para cualquier máquina que intente verificar un hash. Como dijo Xander, generalmente se almacena en una columna diferente de la misma base de datos, o se añade como un número de bytes codificados en caracteres en el resumen del hash.