¿La sal debe ser única o no predecible?

Publiqué una respuesta que explica esto en otra pregunta , lo que debería proporcionarle un buen fondo de todas las principales preocupaciones de seguridad relacionadas con el almacenamiento de contraseña.

Para responder a su pregunta de manera más directa: una sal:

• debe ser único.
• debería ser impredecible.
• debería ser desconocido para los posibles atacantes.

El problema con esquemas como H(pass + username) es que el atacante conoce la sal. Por lo tanto, si bien su capacidad de descifrar todas las contraseñas de la base de datos con una sola tabla de arco iris se ha ido, puede crear una tabla de arco iris para cuentas de usuarios clave. Esto le permite calcular la tabla de arco iris para una cuenta de usuario privilegiada (por ejemplo, admin) por adelantado, y luego usarla inmediatamente una vez que viola la base de datos.

Esto es un problema, porque no le da tiempo para reaccionar ante la violación. Segundos después de que te alerten sobre el ataque, el atacante ha iniciado sesión en tu cuenta de administrador. Si el atacante está obligado a descifrar la contraseña después de la violación, le da tiempo para bloquear cuentas privilegiadas y cambiar las contraseñas.

También puedes buscar en un esquema de sal + pimienta, donde la pimienta es una segunda sal almacenada fuera de la base de datos, por ejemplo. en codigo. Esto ayuda a prevenir contra el modelo de ataque de inyección SQL, donde el malo solo tiene acceso a la base de datos.

La mejor práctica es algo como esto (siéntase libre de omitir el pimiento):

hash = KDF(pass + pepper, salt, workFactor)

Donde:

• KDF es una función de derivación de clave fuerte y lenta, como bcrypt de PBKDF2.
• pass es una contraseña segura (¡haga cumplir las políticas de contraseña!)
• pepper es un valor constante aleatorio largo almacenado en su código.
• salt es un valor único aleatorio largo almacenado con la contraseña en la base de datos.
• workFactor es apropiado para sus requisitos de hardware y seguridad.

Las sales deben ser únicas para cada contraseña.

Si está usando el mismo Salt para cada contraseña, un atacante podría simplemente generar una tabla de arco iris usando ese Salt en particular y descifrar la mayoría de las contraseñas en su base de datos.

Con respecto a los comentarios sobre PBKDF2 y aceleración de GPU, me gustaría señalarle link aquí en Security.SE donde Thomas Pornin dio una respuesta excelente.

Los requisitos exactos para un salt dependen del algoritmo de hash de contraseña, pero para los métodos habituales (bcrypt, PBKDF2 ...) el requisito solo es que el salt es único . O al menos tan único como sea práctico; La extraña colisión no es un gran problema, siempre que no ocurra con frecuencia y no pueda ser forzada desde el exterior.

La unicidad es mundial; no es suficiente que las sales sean únicas en un servidor dado. Dos servidores distintos, que utilizan el mismo algoritmo de hash, también deben tener distintas sales.

Una forma relativamente común y barata de obtener una singularidad mundial es generar sales a partir de un PRNG criptográficamente fuerte, con una longitud suficiente (16 bytes aleatorios son suficientes). Eso es lo que bcrypt hace. Si el PRNG está sesgado, entonces necesita un poco más de sal para lograr la singularidad. Si el PRNG es débil debido a una semilla muy pequeña o un estado interno, entonces la singularidad no se obtendrá satisfactoriamente de esa manera. El nombre de usuario es no una buena sal, por dos razones:

• El mismo nombre de usuario puede aparecer en varios servidores (por ejemplo, cada servidor puede tener una cuenta de "Administrador", con ese nombre exacto);
• El usuario no cambia su nombre cuando cambia su contraseña, lo que lleva a la reutilización de sal.

sales no son lo mismo que las teclas (que son secretas y deben permanecer confidenciales) o vectores de inicialización (IV son "puntos de partida" para algunos algoritmos, y pueden tener requisitos adicionales, como uniformidad e impredecibilidad en el caso de cifrado CBC). Normalmente no hay problema en regalar sus valores de sal; de todos modos, quienquiera que vuelva a calcular el valor de hash de la contraseña debe conocer el salt. Por lo tanto, la publicación de sales es intrínseca con el cifrado de archivos basado en contraseña (la sal se codifica en el encabezado del archivo). También se publica necesariamente en protocolos de autenticación donde el hashing se produce en el cliente (eso es bastante raro en contextos web, porque Javascript es demasiado lento). No tiene sentido publicar las sales innecesariamente, pero mantenerlas en secreto tampoco mejora la seguridad.

En esta respuesta , se evoca un escenario marginal: un el atacante aprende la sal de antemano, prepara una gran tabla precomputada, luego ejecuta el ataque real que revela el hash de la contraseña. Esto no facilita que el atacante rompa la contraseña; de hecho, esto aumenta su esfuerzo (tiene que producir una tabla completa en lugar de detenerse cuando se encuentra la contraseña, por lo que el costo es doble en promedio; si la tabla es de la tendencia del arco iris, un factor adicional de 1.7 ingresa para la generación de la tabla; y hay costos de almacenamiento). Lo que cambia es la dinámica : esto acorta el tiempo entre el robo (el valor de hash es robado) y la recuperación de la contraseña. Este es un caso de borde, así que no se preocupe. Si utiliza el hashing de contraseña para el almacenamiento en un protocolo de autenticación, donde el hashing se produce en el lado del servidor, simplemente almacene la sal con el valor de hash y las sales serán tan confidenciales como los valores de hash, y eso es bueno. En otros casos (por ejemplo, el cifrado de archivos basado en contraseñas), las sales serán más "públicas", pero eso no es crítico de ninguna manera, así que no agregue complejidad adicional para mantener las sales en secreto (la complejidad adicional es mala, y mucho más. peor que las sales públicas).