Realmente no entiendo cómo funciona la salazón. Leí el artículo de Wikipedia , pero aún no entiendo cómo puede un sistema autenticar un hash salado.
Digamos que un usuario elige una contraseña. Es al azar salado y picado. Ahora, cuando ese usuario desea volver a iniciar sesión, su contraseña se revisa nuevamente y se compara con la contraseña guardada con sal y guardada de la última vez. Los hashes no coincidirán, ¿verdad?
Quiero decir, supongo que coinciden de alguna manera. Pero ¿cómo?
Cuando hash la contraseña la primera vez (cuando el usuario se registra), usas un salt y almacenas tanto el salt como el hash resultante en la base de datos.
La segunda vez (cuando intentan iniciar sesión nuevamente), usas tu nombre de usuario para extraer el salt y el hash de la base de datos. Utiliza el salt para hacer hash en su entrada de contraseña y comparar los dos hashes.
Puede que se esté preguntando "pero si alguien obtiene acceso a mi base de datos, tiene todas las sales, ¿no es este un gran problema?". El hecho de que tengan las sales no es un problema, ya que el propósito de la sal no es agregar algo "secreto", es asegurarse de que si dos usuarios tienen la misma contraseña tienen diferentes hashes ya que los hashes fueron creados con diferentes sales.
Si no usó sales, o si usó exactamente la misma sal para cada usuario (desafortunadamente no es un error poco común), habrá muchos hashes duplicados (ya que algunas personas usarán la misma contraseña, y esas todas las contraseñas idénticas tendrán hashes idénticos). Si alguien tiene acceso a su base de datos, puede buscar los hashes que aparecen con mayor frecuencia, concentrarse en descifrar esos hashes y, para cada uno de ellos, pueden acceder a múltiples cuentas. Al exprimir cada hash de manera diferente, es muy probable que no haya hashes duplicados; las diferentes sales significan que incluso las contraseñas duplicadas tendrán hashes diferentes. Por cada hash que rompen, obtienen acceso a una sola cuenta, no más. Ese es el propósito de la sal.
La sal se almacena con el hash, por ejemplo, en un campo de base de datos independiente o se etiqueta en el final del hash o el nombre de usuario se usa como la sal.
El propósito es que incluso si dos usuarios tienen la misma contraseña, sus sales serán diferentes y sus hashes no serán las mismas.
Esto es útil si alguien se las arregla para robar la base de datos, tendrán que romper cada combinación de hash + sal por separado. Entonces, en el caso de nuestros dos usuarios que comparten la misma contraseña, el atacante no sabrá que son iguales hasta que los agrupe a ambos.
También es cierto que, sin las sales, un atacante puede realizar los hashes de las contraseñas comunes y verificarlas contra la base de datos robada. El salado hace que estas tablas de arco iris generadas sean inútiles.
El usuario siempre envía la contraseña real al servidor y el servidor almacena los valores de sal y hash. El objetivo de un salt es simplemente asegurarse de que, si la base de datos se ve comprometida, un atacante no puede intentar forzar a todos los contraseñas a la vez. También evita la identificación de contraseñas reutilizadas.
No importa si la sal se convierte en información pública, ya que no reduce el trabajo del atacante para saber la sal, ya que solo tienen que probar todas las contraseñas hasta obtener una coincidencia. El hashing se realiza en el servidor para que el cliente no pueda simplemente devolver el hash como se ve en la base de datos sin tener que conocer la contraseña.
Grandes respuestas hasta ahora, pero algo que creo que también debería mencionarse porque no está muy claro en el artículo al que hace referencia. La función de hashing se ejecuta contra el salt concatenado junto con la contraseña y luego el salt se concatena nuevamente con el hash resultante de la función y esa cadena es lo que se almacena en la base de datos de contraseñas como / etc / shadow.
Este ejemplo muestra lo que sucede cuando un usuario elige su contraseña en un sistema Unix, cómo se almacena en / etc / shadow y luego cómo se verifica la contraseña cuando el usuario inicia sesión. Voy a utilizar ejemplos reales en su lugar. de nombres de variables o cadenas como foobar. También voy a ignorar cosas como pam para hacer esto un poco más simple.
La entrada completa en / etc / shadow se ve así:
monroe:$6$BohpaS.aul0Qua/t$IVUen1dSKZ634jM.KLQ1Am/WPh..DSO2MYI53qffac2IFzESKwIufyVjzQGlxNenOXGehMTCdSoL9DLPe6Zfm1:15196:0:99999:7:::
La parte de $ 6 $ indica que fue SHA-512 hash. La parte intermedia entre el segundo y el tercer carácter '$' almacena la sal que se utilizó. Este campo en el archivo de la sombra se llama el campo cifrado. A algunas personas no les gusta ese nombre porque está encriptado, no encriptado. Cifrado implica que se puede descifrar, lo que no se puede descifrar. Sin embargo, me referiré a él como el campo de contraseña cifrada.
Esperemos que esto demuestre por qué el algoritmo de hash solo necesita ser un algoritmo de una manera y cómo se usa exactamente la sal.
El motivo del archivo shadow es que el archivo / etc / password necesita ser legible en todo el mundo en un sistema Unix. Solían almacenar la contraseña cifrada (y hace mucho tiempo incluso la contraseña de texto claro) en el segundo campo del archivo / etc / password. Lo movieron al archivo de la sombra y solo le dieron acceso de root a ese archivo y el mecanismo de autenticación necesita privilegios de root para autenticarse.
Bueno, eso terminó siendo mucho más largo de lo que pensé.
Lea otras preguntas en las etiquetas passwords authentication hash salt