¿Por qué las sales para las contraseñas de hash deben ser globalmente únicas, no solo del sistema / sitio?

El objetivo de la salazón es resistencia a la precomputación .

Si bien no puede garantizar que una sal es única a nivel mundial, puede (como usted dijo) generar sales de tamaño suficiente para que sea imposible generar un rainbow table por adelantado (haciéndolos" lo suficientemente únicos ").

Más generalmente, si está preguntando sobre cómo crear una sal, parece que está lanzando su propio método de hashing, que puede ser educativo pero generalmente no se recomienda.

En su lugar, use un hash existente (como PBDKF2 o bcrypt) (o incluso mejor, como CBHacking sugiere correctamente en los comentarios, scrypt o Argon2). No solo heredará automáticamente sus métodos de salado existentes (que son suficientes), sino que su experimentación se alineará con las mejores prácticas de almacenamiento de contraseñas ... lo que probablemente sería una mejor práctica.

Actualización 2018-04-03 : Steve Thomas (sc00bz) hace un buen punto aquí que Argon2 y scrypt son en realidad peores para el defensor cuando se usan a velocidades generalmente consideradas compatibles con la autenticación a escala (< 0.1 segundos), mientras que son mejores para el defensor para velocidades compatibles con el cifrado de archivos individuales (1 a 5 segundos) ). (Esto significa que la brecha de 0.1 segundos a 1 segundo es probablemente interesante, y soporta pruebas para su entorno específico). En otras palabras, su afirmación es que si intenta ajustar Argon2 o scrypt a velocidades de < 0.1s, los resultados son menos resistentes al agrietamiento que bcrypt a esas velocidades.

En el mismo hilo, Aaron Toponce también hace una gran sugerencia para trabajar alrededor de la longitud de bcrypt (72 caracteres máximo) y limitaciones de pre-hashing, utilizando bcrypt(base64(sha-256(password))) . (Consulte también la respuesta similar de Thomas Pornin aquí ). La razón por la que se necesita la base64 también es interesante : no déjalo fuera.

Entonces, si su caso de uso es una autenticación escalable y resistente a las grietas con una experiencia de autenticación rápida, bcrypt(base64(sha-256(password))) es probablemente un buen enfoque. (Y deberá ajustar el factor de trabajo de bcrypt al valor más alto que se ajuste a su ventana de velocidad de autenticación). Si sus usuarios pueden tolerar esperar un segundo o más para autenticarse, Argon2i o Scrypt pueden ser mejores. Y tenga en cuenta que el rendimiento relativo cambiará con el tiempo, a medida que mejoren las capacidades del hardware, por lo que aumentar el factor de trabajo de bcrypt cada X meses para nuevos hashes (como lo hace Dropbox) permitiría que el enfoque se adapte a las capacidades futuras con el tiempo.

No hay ninguna ventaja en usar la dirección de correo electrónico en lugar de generar un valor aleatorio. De todos modos, debe almacenarlo como el salt aleatorio, de lo contrario, el usuario nunca podrá cambiar la dirección de correo electrónico.

La singularidad global no es un requisito, no es necesario garantizar la singularidad, pero cuanto más globalmente únicas sean las sales, mejor. Las posibles combinaciones para una sal de 128 bits (BCrypt) son 3E38. Incluso si genera 1000 sales / seg, se esperaría que aproximadamente 6E8 años esperen un 50% de probabilidad de duplicado.

Como ya mencionó Royce, los algoritmos de hoy ya generan la sal para usted, y la almacenan como texto plano en la cadena de hash resultante, por lo que no hay necesidad de un manejo especial en la base de datos (solo 1 campo para el hash).

Al usar direcciones de correo electrónico, un atacante podría calcular previamente las tablas de arco iris para ciertos correos electrónicos de interés.

Si bien las desventajas no son fatales en la práctica, simplemente no hay ventajas, ¿por qué elegiría un método más complicado y menos seguro para generar la sal? Usa una función hash de contraseña moderna y eres bueno.

Este tema se vuelve mucho más claro si, en lugar de decir que las sales "necesitan" ser únicas a nivel mundial, observamos que, en caso afirmativo, se logra una seguridad óptima.

Considere el siguiente modelo de ataque simplista: un atacante obtiene n de las entradas de contraseña, y tienen los recursos para realizar m de pruebas en total. Ahora considera los casos extremos:

• Si las contraseñas no tienen sal (o todas tienen la misma sal), cada uno de los cálculos de m se puede comparar con todas las entradas de n . Lo que significa que pueden probar las hipótesis de usuario / contraseña m * n .
• Si todas las contraseñas están incluidas con sales únicas, entonces cada uno de los cálculos de m solo se puede comparar con 1 entrada. Lo que significa que solo llegan a probar las hipótesis de usuario / contraseña m .

Si algunas de las sales, pero no todas, son duplicados, el atacante obtiene algo intermedio, proporcional al número de sales distintas. Pero esto no significa que la salazón falle catastróficamente en la duplicación de sal, sino que su efectividad se degrada linealmente.

Dado que las sales aleatorias lo suficientemente grandes son generalmente fáciles de implementar y logran unicidad global con casi todas las posibilidades, pero realmente hay muy pocas razones para no ir por ese camino.

Las sales aleatorias tienen otra propiedad importante, que la respuesta de martinstoeckli a la pregunta que vincula señala: el atacante no puede predice de antemano qué sales utilizarás. Su propuesta para utilizar direcciones de correo electrónico no cumple con ese criterio.