En Linux tenemos la sal justo al lado del hash de contraseña en el archivo / etc / shadows.
Siempre escucho que el valor de sal evita que las contraseñas con hash sean crackeadas por métodos de fuerza bruta. Pero si de alguna manera obtenemos el archivo de sombra, podemos inyectar la sal en el algoritmo y seguir usando un método de fuerza bruta, ¿verdad?
No estoy considerando el tiempo empleado, solo la idea general. Sé que el brute forzar un hash SHA256 o SHA512 tomará para siempre.
Hashear la contraseña con un salt hace que sea más difícil para un atacante usar una lista de hashes precomputada (también conocida como tablas rainbow) para ejecutar el hash descubierto en contra.
Lo forzará a calcular los hashes nuevamente para cualquier hash de contraseña con sal que quiera descifrar.
La sal no tiene que ser secreta. Sin embargo, DEBE ser único para cada contraseña. Considere esto: si todas sus contraseñas están encriptadas con la misma sal, entonces un atacante que obtiene acceso a su base de datos "solo" debe calcular H (pwd + sal) para cada valor pwd posible y obtiene todas sus contraseñas. Sin embargo, si la sal es única, la misma operación solo le dará una contraseña, la que está asociada con la sal que acaba de probar.
Una sal no no hace que sea más difícil forzar la aplicación de una contraseña única, como lo señalaste correctamente.
Sin un salt, un atacante podría construir una única tabla de arco iris, y obtendría todas las contraseñas a la vez. Con una sal, el atacante tiene que construir una tabla de arco iris para exactamente esta sal, por lo que no puede reutilizar las tablas de arco iris ya existentes. Cuando se usa una sal única diferente para cada contraseña, entonces un atacante tendría que construir una tabla de arco iris para cada contraseña. Esto no tiene sentido, después de encontrar una coincidencia, no hay ninguna ventaja para terminar esta tabla de arco iris, ya que la fuerza bruta es más barata.
Con una sal única por contraseña, no se puede usar una tabla arco iris precalculada para obtener varias contraseñas a la vez.
Esto también responde a la pregunta, por qué la sal no necesita ser secreta. Los algoritmos como SHA- * no son adecuados para las contraseñas de hash, porque son demasiado rápidos y, por lo tanto, pueden forzarse con la fuerza bruta con demasiada facilidad. Utilícelos junto con PBKDF2 o use Bcrypt / Scrypt, que ofrecen un factor de costo.
Tienes razón. Salting realmente hace que el pirateo de la contraseña sea más difícil para las contraseñas no triviales, pero si algunos usuarios usan contraseñas comunes, todavía pueden hackear la contraseña mediante fuerza bruta unas cuantas veces.
Si la sal es pública / se almacena junta, como en su caso, solo se usa para evitar la búsqueda de hashes de contraseña pre-calculada, es decir, tabla de arco iris.
Por lo tanto, si se tratara de algoritmos similares en aplicaciones web, sugeriría que también puede preparar una clave secreta constante específica de la aplicación para la contraseña de los usuarios, antes de aplicar hashing con el algoritmo salado. Por supuesto, si se filtra la clave secreta de la aplicación, esta mejora de seguridad desaparecerá. Por lo tanto, almaceno esa clave secreta en el código para separarla de la base de datos de hashes de contraseña. (Eso es inalcanzable en el archivo shadow de Linux)
Comentario adicional : el punto principal de agregar la "clave secreta" (o pimienta) extra: incluso el hash de una contraseña simple no puede ser una fuerza bruta solo unos pocos miles de veces para descifrarla ( son tan difíciles como contraseñas complicadas a fuerza bruta), dado que el pirata informático solo conoce el hash de la contraseña, pero aún no puede ver la clave secreta en su código. (Mientras tanto, no protege los intentos de fuerza bruta de la contraseña del sitio web, guarda el intento fuera de línea de descifrar el hash solo)
Hace que un ataque de diccionario sea mucho más difícil, si la sal se crea de manera inteligente. Por ejemplo, bcrypt utiliza un sal de 128 bits .
Una sal se genera generalmente al azar. Si se derivara solo de la contraseña o del hash de la contraseña, de hecho no agregaría mucha seguridad. Si se genera de una manera que el atacante no puede predecir, aumenta significativamente el espacio de búsqueda, lo que hace que el ataque de fuerza bruta requiera mucha más fuerza bruta.
Tenga en cuenta que incluso en un ataque de fuerza bruta, un atacante intentará con las contraseñas predecibles (como "pa $$ w0rd") primero. Suponiendo una sal de 128 bits impredecible, el atacante ahora tiene que probar hasta 2 ^ 128 posibilidades más para romper el hash de "pa $$ w0rd" + sal. En promedio, será la mitad de 2 ^ 128 posibilidades antes de que el atacante tenga éxito, lo que sigue siendo 2 ^ 127 posibilidades más.