Sal no aleatoria para hashes de contraseña

ACTUALIZACIÓN: Recientemente aprendí de esta pregunta que en toda la discusión a continuación, yo (y estoy seguro de que otros también lo hicieron) fue un poco confuso: lo que sigo llamando una tabla de arco iris, de hecho se llama una tabla hash. Las tablas de arco iris son criaturas más complejas y en realidad son una variante de Hellman Hash Chains. Aunque creo que la respuesta sigue siendo la misma (ya que no se reduce al criptoanálisis), parte de la discusión puede estar un poco sesgada.
La pregunta: " ¿Qué son las tablas arcoíris y cómo se usan? "

Por lo general, siempre recomiendo usar un valor aleatorio criptográficamente fuerte como salt, para usarlo con funciones hash (por ejemplo, para contraseñas), como para protegerse contra ataques de Rainbow Table.

Pero, ¿es realmente criptográficamente necesario que la sal sea aleatoria? ¿Sería suficiente algún valor único (único por usuario, por ejemplo, userId) a este respecto? De hecho, evitaría el uso de una sola Tabla Rainbow para descifrar todas (o la mayoría) de las contraseñas del sistema ...
Pero, ¿la falta de entropía realmente debilita la fuerza criptográfica de las funciones hash?

Tenga en cuenta que no estoy preguntando por qué usar sal, cómo protegerla (no es necesario), usar un solo hash constante (no hacerlo) o qué tipo de función hash usar.
Si la sal necesita entropía o no.

Gracias a todos por las respuestas hasta ahora, pero me gustaría centrarme en las áreas con las que estoy (un poco) menos familiarizado. Principalmente implicaciones para el criptoanálisis: lo agradecería más si alguien tuviera alguna información del punto de vista cripto-matemático.
Además, si hay vectores adicionales que no se han considerado, también es una gran entrada (ver el punto de @Dave Sherohman en múltiples sistemas).
Más allá de eso, si tiene alguna teoría, idea o mejor práctica, respalde esto con pruebas, escenarios de ataque o evidencia empírica. O incluso consideraciones válidas para compensaciones aceptables ... Estoy familiarizado con las Mejores Prácticas (B mayúscula P) sobre el tema, me gustaría demostrar qué valor proporciona realmente.

EDITAR: Algunas respuestas realmente buenas aquí, pero creo que, como dice @Dave, se reduce a Rainbow Tables para nombres de usuarios comunes ... y posibles nombres menos comunes también. Sin embargo, ¿qué pasa si mis nombres de usuario son únicos a nivel mundial? No es necesariamente único para mi sistema, sino para cada usuario, por ejemplo, dirección de correo electrónico.
No habría ningún incentivo para construir un RT para un solo usuario (como enfatizó @Dave, la sal no se mantiene en secreto), y esto aún evitaría la agrupación en clústeres. El único problema sería que podría tener el mismo correo electrónico y contraseña en un sitio diferente, pero la sal no lo evitaría de todos modos.
Entonces, todo se reduce al criptoanálisis: ¿ES la entropía necesaria o no? (Mi pensamiento actual es que no es necesario desde el punto de vista del criptoanálisis, sino por otras razones prácticas).

La sal se almacena tradicionalmente como un prefijo de la contraseña hash. Esto ya lo da a conocer a cualquier atacante con acceso al hash de la contraseña. Usar el nombre de usuario como salt o no no afecta ese conocimiento y, por lo tanto, no tendría ningún efecto en la seguridad de un solo sistema.

Sin embargo, usar el nombre de usuario o cualquier otro valor controlado por el usuario como sal reduciría la seguridad entre sistemas, ya que un usuario que tuviera el mismo nombre de usuario y contraseña en varios sistemas que usaran el mismo algoritmo de hash de contraseña terminaría con el mismo hash de contraseña en cada uno de esos sistemas. No considero que esto sea una responsabilidad importante porque yo, como atacante, primero probaría contraseñas que se sabe que una cuenta objetivo ha usado en otros sistemas antes de intentar cualquier otro medio de comprometer la cuenta. Los hash idénticos solo me dirían de antemano que la contraseña conocida funcionaría, no facilitarían el ataque real. (Tenga en cuenta, sin embargo, que una comparación rápida de las bases de datos de la cuenta proporcionaría una lista de objetivos de mayor prioridad, ya que me diría quién está reutilizando contraseñas y quién no).

El mayor peligro de esta idea es que los nombres de usuario se reutilizan comúnmente; casi cualquier sitio que desee visitar tendrá una cuenta de usuario llamada "Dave", por ejemplo, y "admin" o "root" son aún más comunes, lo que haría la construcción de tablas de arco iris dirigidas a usuarios con esos nombres comunes es mucho más fácil y eficaz.

Ambos defectos podrían abordarse de manera efectiva agregando un segundo valor de sal (ya sea fijo y oculto o expuesto como sal estándar) a la contraseña antes de aplicar el hash, pero, en ese punto, es posible que simplemente esté usando sal entrópica estándar de todos modos. de trabajar el nombre de usuario en él.

Editado para agregar: mucha gente está hablando de entropía y si la entropía en la sal es importante. Lo es, pero no por la razón que la mayoría de los comentarios parecen pensar.

La idea general parece ser que la entropía es importante, por lo que la sal será difícil de adivinar para un atacante. Esto es incorrecto y, de hecho, completamente irrelevante. Como varias personas han señalado algunas veces, los ataques que se verán afectados por salt solo pueden ser realizados por alguien con la base de datos de contraseñas y alguien con la base de datos de contraseñas puede simplemente mirar para ver cuál es el salt de cada cuenta. Si se puede adivinar o no, no importa cuándo puede buscarlo trivialmente.

La razón por la que la entropía es importante es evitar la agrupación de valores de sal. Si la sal se basa en el nombre de usuario y sabe que la mayoría de los sistemas tendrán una cuenta llamada "root" o "admin", entonces puede hacer una tabla de arco iris para esas dos sales y romperá la mayoría de los sistemas. Si, por otro lado, se usa una sal aleatoria de 16 bits y los valores aleatorios tienen una distribución aproximadamente uniforme, entonces necesita una tabla de arco iris para las 2 ^ 16 sales posibles.

No se trata de evitar que el atacante sepa cuál es la sal de una cuenta individual, se trata de no darles el objetivo grande y gordo de una sola sal que se utilizará en una proporción sustancial de objetivos potenciales.

El uso de una sal de alta entropía es absolutamente necesario para almacenar las contraseñas de forma segura.

Tome mi nombre de usuario 'gs' y agréguelo a mi contraseña 'MyPassword' le da gsMyPassword. Esto se puede romper fácilmente usando una tabla de arco iris porque si el nombre de usuario no tiene suficiente entropía, podría ser que este valor ya esté almacenado en la tabla de arco iris, especialmente si el nombre de usuario es corto.

Otro problema son los ataques en los que se sabe que un usuario participa en dos o más servicios. Hay muchos nombres de usuario comunes, probablemente los más importantes son admin y root. Si alguien creara una tabla de arcoíris que tuviera sales con los nombres de usuario más comunes, podría usarlas para comprometer cuentas.

Solían tener una sal de 12 bits . 12 bits son 4096 combinaciones diferentes. Eso no era lo suficientemente seguro porque esa gran cantidad de información se puede almacenar fácilmente hoy en día . Lo mismo se aplica a los 4096 nombres de usuario más utilizados. Es probable que algunos de sus usuarios elijan un nombre de usuario que pertenezca a los nombres de usuario más comunes.

Encontré este verificador de contraseñas que calcula la entropía de su contraseña. Tener una entropía más pequeña en las contraseñas (como usar nombres de usuario) hace que sea mucho más fácil para las tablas de arco iris, ya que intentan cubrir al menos todas las contraseñas con entropía baja, porque es más probable que ocurran.

Es cierto que el nombre de usuario por sí solo puede ser problemático, ya que las personas pueden compartir nombres de usuario entre diferentes sitios web. Pero no debería ser problemático si los usuarios tuvieran un nombre diferente en cada sitio web. Entonces, ¿por qué no hacerlo único en cada sitio web? Hash la contraseña algo así

hashfunction ("www.yourpage.com /" + nombre de usuario + "/" + contraseña)

Esto deberia resolver el problema. No soy un maestro del criptoanálisis, pero dudo que el hecho de que no usemos alta entropía debilitaría el hash.

Me gusta usar ambos: una sal por registro aleatoria de alta entropía, más la identificación única del registro en sí.

Aunque esto no agrega mucho a la seguridad contra ataques de diccionario, etc., elimina el caso marginal en el que alguien copia su sal y hash en otro registro con la intención de reemplazar la contraseña con la suya propia.

(Es cierto que es difícil pensar en una circunstancia en la que esto se aplique, pero no veo ningún daño en los cinturones y aparatos ortopédicos cuando se trata de seguridad).

Si la sal es conocida o fácil de adivinar, no ha aumentado la dificultad de un ataque de diccionario. Incluso puede ser posible crear una tabla de arco iris modificada que tenga en cuenta una sal "constante".

El uso de sales únicas aumenta la dificultad de los ataques de diccionario BULK.

Sería ideal tener un valor de sal único y criptográficamente fuerte.

Diría que siempre que la sal sea diferente para cada contraseña, probablemente estará bien. El punto de la sal es que no puede usar la tabla de arco iris estándar para resolver todas las contraseñas en la base de datos. Entonces, si aplica una sal diferente a cada contraseña (incluso si no es aleatoria), el atacante básicamente tendría que calcular una nueva tabla de arco iris para cada contraseña, ya que cada contraseña usa una sal diferente.

Usar una sal con más entropía no ayuda mucho, porque en este caso se supone que el atacante ya tiene la base de datos. Dado que necesita poder recrear el hachís, ya debe saber qué es la sal. Por lo tanto, debe almacenar la sal o los valores que componen la sal en su archivo de todos modos. En sistemas como Linux, el método para obtener la sal es conocido, por lo que no sirve de nada tener una sal secreta. Debe asumir que el atacante que tiene sus valores hash probablemente también conozca sus valores de sal.

¡La fuerza de una función hash no está determinada por su entrada!

El uso de una sal que sea conocida por el atacante obviamente hace que la construcción de una tabla de arcoíris (particularmente para nombres de usuario codificados como root ) sea más atractiva, pero no debilita el hash . El uso de una sal desconocida para el atacante hará que el sistema sea más difícil de atacar.

La concatenación de un nombre de usuario y una contraseña aún podría proporcionar una entrada para una tabla de arco iris inteligente, por lo que usar una sal de una serie de caracteres pseudoaleatorios, almacenados con la contraseña hash es probablemente una mejor idea. Como ilustración, si tuviera el nombre de usuario "papa" y la contraseña "cerveza", la entrada concatenada para su hash es "papa cerveza", que es una entrada razonable para una tabla de arco iris.

Cambiar la sal cada vez que el usuario cambia su contraseña podría ayudar a derrotar ataques prolongados, al igual que la aplicación de una política de contraseña razonable, por ejemplo, mayúsculas y minúsculas, puntuación, longitud mínima, cambio después de n semanas.

Sin embargo, diría que su elección de algoritmo de resumen es más importante. El uso de SHA-512 resultará más complicado para alguien que genere una tabla de arcoíris que MD5, por ejemplo.

Salt debe tener tanta entropía como sea posible para garantizar que, si un valor de entrada dado se utiliza con hash varias veces, el valor de hash resultante será, lo más cercano posible, siempre diferente.

El uso de valores de sal en constante cambio con la mayor entropía posible en la sal garantizará que la probabilidad de hash (por ejemplo, contraseña + sal) produzca valores de hash completamente diferentes.

Cuanto menos entropía haya en la sal, más posibilidades tendrá de generar el mismo valor de sal, por lo que tendrá más posibilidades de generar el mismo valor hash.

Es la naturaleza de que el valor hash sea "constante" cuando la entrada es conocida y "constante" lo que permite que los ataques de diccionario o las tablas de arco iris sean tan efectivos. Al variar el valor de hash resultante tanto como sea posible (mediante el uso de valores de sal de alta entropía), se asegura que el hash de la misma entrada + sal aleatoria producirá muchos resultados de valor de hash diferentes, derrotando (o al menos reduciendo en gran medida la efectividad de) la tabla de arco iris Ataques

La entropía es el punto de valor de la sal.

Si hay alguna "matemática" simple y reproducible detrás de la sal, entonces es lo mismo que la sal no está ahí. Solo agregar valor de tiempo debería estar bien.