¿Cómo ayuda la sal de contraseña contra un ataque de mesa arcoiris?

Tengo problemas para entender el propósito de una sal a una contraseña. Tengo entendido que el uso principal es obstaculizar un ataque de la mesa del arco iris. Sin embargo, los métodos que he visto para implementar esto no parecen realmente dificultar el problema.

He visto muchos tutoriales que sugieren que la sal se use de la siguiente manera:

$hash =  md5($salt.$password)

El razonamiento es que el hash ahora no se asigna a la contraseña original, sino a una combinación de la contraseña y la sal. Pero di $salt=fooy $password=bary $hash=3858f62230ac3c915f300c664312c63f. Ahora, alguien con una tabla de arcoíris podría revertir el hash y generar la entrada "foobar". Luego podrían probar todas las combinaciones de contraseñas (f, fo, foo, ... oobar, obar, bar, ar, ar). Puede tomar algunos milisegundos más obtener la contraseña, pero no mucho más.

El otro uso que he visto es en mi sistema Linux. En / etc / shadow, las contraseñas hash se almacenan realmente con la sal. Por ejemplo, una sal de "foo" y la contraseña de "barra" sería hash en esto: $1$foo$te5SBM.7C25fFDu6bIRbX1. Si un pirata informático pudo de alguna manera tener en sus manos este archivo, no veo para qué sirve la sal, ya que te5SBM.7C25fFDu6bIRbXse sabe que el hash inverso contiene "foo".

Gracias por cualquier luz que alguien pueda arrojar sobre esto.

EDITAR : Gracias por la ayuda. Para resumir lo que entiendo, la sal hace que la contraseña hash sea más compleja, por lo que es mucho menos probable que exista en una tabla de arco iris precalculada. Lo que antes entendí mal fue que estaba asumiendo que existía una mesa arcoiris para TODOS los hashes.

Una sal pública no hará que los ataques de diccionario sean más difíciles al descifrar una sola contraseña. Como ha señalado, el atacante tiene acceso tanto a la contraseña cifrada como a la sal, por lo que cuando ejecuta el ataque del diccionario, simplemente puede usar la sal conocida al intentar descifrar la contraseña.

Una sal pública hace dos cosas: hace que sea más lento descifrar una gran lista de contraseñas, y no es factible usar una tabla arcoíris.

Para comprender el primero, imagine un solo archivo de contraseña que contenga cientos de nombres de usuario y contraseñas. Sin sal, podría calcular "md5 (intento [0])" y luego escanear el archivo para ver si ese hash aparece en alguna parte. Si hay sales, entonces tengo que calcular "md5 (sal [a]. Intento [0])", comparar con la entrada A, luego "md5 (sal [b]. Intentar [0])", comparar con la entrada B , etc. Ahora tengo nmucho más trabajo que hacer, ¿dónde nestá la cantidad de nombres de usuario y contraseñas que contiene el archivo?

Para entender la segunda, debes entender qué es una mesa arcoiris. Una tabla de arcoíris es una gran lista de hashes precalculados para contraseñas de uso común. Imagine nuevamente el archivo de contraseña sin sales. Todo lo que tengo que hacer es revisar cada línea del archivo, extraer la contraseña cifrada y buscarla en la tabla del arco iris. Nunca tengo que calcular un solo hash. Si la búsqueda es considerablemente más rápida que la función hash (lo que probablemente sea), esto acelerará considerablemente el craqueo del archivo.

Pero si el archivo de contraseña está salado, entonces la tabla del arco iris tendría que contener "sal. Contraseña" pre-hash. Si la sal es suficientemente aleatoria, esto es muy poco probable. Probablemente tenga cosas como "hola" y "foobar" y "qwerty" en mi lista de contraseñas pre-hash de uso común (la tabla del arco iris), pero no voy a tener cosas como "jX95psDZhello" o "LPgB0sdgxfoobar" o "dZVUABJtqwerty" precalculado. Eso haría que la mesa del arcoíris fuera prohibitivamente grande.

Entonces, la sal reduce al atacante de nuevo a una computación por fila por intento que, cuando se combina con una contraseña suficientemente larga y suficientemente aleatoria, es (en términos generales) indescifrable.

Las otras respuestas no parecen abordar sus malentendidos sobre el tema, así que aquí va:

Dos usos diferentes de la sal.

He visto muchos tutoriales que sugieren que la sal se use de la siguiente manera:

$hash = md5($salt.$password)

[...]

El otro uso que he visto es en mi sistema Linux. En / etc / shadow, las contraseñas hash se almacenan realmente con la sal.

Usted siempre tiene que almacenar la sal con la contraseña, porque a fin de validar lo que el usuario ha introducido en contra de su base de datos de contraseñas, hay que combinar la entrada con la sal, el hash y compararlo con el hash almacenado.

Seguridad del hash

Ahora, alguien con una tabla de arcoíris podría revertir el hash y generar la entrada "foobar".

[...]

ya que se sabe que el hash inverso de te5SBM.7C25fFDu6bIRbX contiene "foo".

No es posible revertir el hash como tal (en teoría, al menos). El hash de "foo" y el hash de "saltfoo" no tienen nada en común. Cambiar incluso un bit en la entrada de una función hash criptográfica debería cambiar completamente la salida.

Esto significa que no puede construir una tabla de arco iris con las contraseñas comunes y luego "actualizarla" con algo de sal. Tienes que tener en cuenta la sal desde el principio.

Esta es la razón por la cual necesitas una mesa arcoiris en primer lugar. Como no puede acceder a la contraseña desde el hash, calcula previamente todos los hash de las contraseñas más probables y luego compara sus hash con sus hash.

Calidad de la sal

Pero decir $salt=foo

"foo" sería una muy mala elección de sal. Normalmente usaría un valor aleatorio, codificado en ASCII.

Además, cada contraseña tiene su propia sal, diferente (con suerte) de todas las demás sales del sistema. Esto significa que el atacante debe atacar cada contraseña individualmente en lugar de tener la esperanza de que uno de los hashes coincida con uno de los valores de su base de datos.

El ataque

Si un pirata informático pudo de alguna manera tener en sus manos este archivo, no veo para qué sirve la sal,

Un ataque de la tabla del arco iris siempre necesita /etc/passwd(o cualquier base de datos de contraseñas que se use), o de lo contrario, ¿cómo compararía los valores hash de la tabla del arco iris con los valores hash de las contraseñas reales?

En cuanto al propósito: digamos que el atacante quiere construir una tabla de arco iris para 100,000 palabras en inglés de uso común y contraseñas típicas (piense en "secreto"). Sin sal, tendría que precalcular 100,000 hashes. Incluso con la sal de UNIX tradicional de 2 caracteres (cada uno es una de las 64 opciones [a–zA–Z0–9./]:) tendría que calcular y almacenar 4,096,000,000 hashes ... una gran mejora.

La idea con la sal es hacer que sea mucho más difícil adivinar con fuerza bruta que una contraseña normal basada en caracteres. Las tablas de arcoíris a menudo se construyen con un carácter especial en mente, y no siempre incluyen todas las combinaciones posibles (aunque pueden).

Por lo tanto, un buen valor de sal sería un entero aleatorio de 128 bits o más. Esto es lo que hace que los ataques de la mesa arcoiris fallen. Al usar un valor de sal diferente para cada contraseña almacenada, también se asegura de que una tabla de arco iris construida para un valor de sal en particular (como podría ser el caso si es un sistema popular con un único valor de sal) no le da acceso a todos contraseñas a la vez.

Otra gran pregunta, con muchas respuestas bien pensadas: ¡+1 a SO!

Un pequeño punto que no he visto mencionado explícitamente es que, al agregar una sal aleatoria a cada contraseña, prácticamente está garantizando que dos usuarios que eligieron la misma contraseña producirán hashes diferentes.

¿Porque es esto importante?

Imagine la base de datos de contraseñas en una gran compañía de software en el noroeste de los Estados Unidos. Supongamos que contiene 30,000 entradas, de las cuales 500 tienen la contraseña pantalla azul . Supongamos además que un hacker logra obtener esta contraseña, por ejemplo, leyéndola en un correo electrónico del usuario al departamento de TI. Si las contraseñas no tienen sal, el pirata informático puede encontrar el valor hash en la base de datos, luego simplemente haga coincidir el patrón para obtener acceso a las otras 499 cuentas.

Salar las contraseñas garantiza que cada una de las 500 cuentas tenga una única (sal + contraseña), generando un hash diferente para cada una de ellas y, por lo tanto, reduciendo el incumplimiento a una sola cuenta. Y esperemos, contra toda probabilidad, que cualquier usuario lo suficientemente ingenuo como para escribir una contraseña de texto sin formato en un mensaje de correo electrónico no tenga acceso a la API no documentada para el próximo sistema operativo.

Estaba buscando un buen método para aplicar sales y encontré este excelente artículo con código de muestra:

http://crackstation.net/hashing-security.htm

El autor recomienda usar sales aleatorias por usuario, de modo que obtener acceso a una sal no hará que la lista completa de hashes sea tan fácil de descifrar.

Para almacenar una contraseña:

• Genere una sal larga al azar usando un CSPRNG.
• Anteponga la sal a la contraseña y hágala hash con una función hash criptográfica estándar como SHA256.
• Guarde la sal y el hash en el registro de la base de datos del usuario.

Para validar una contraseña:

• Recupere la sal y el hash del usuario de la base de datos.
• Anteponga la sal a la contraseña dada y diviértala con la misma función hash.
• Compare el hash de la contraseña dada con el hash de la base de datos. Si coinciden, la contraseña es correcta. De lo contrario, la contraseña es incorrecta.

La razón por la que una sal puede hacer que falle un ataque de la mesa del arco iris es que para n bits de sal, la mesa del arco iris tiene que ser 2 ^ n veces más grande que el tamaño de la tabla sin la sal.

Su ejemplo de usar 'foo' como sal podría hacer que la mesa del arco iris sea 16 millones de veces más grande.

Dado el ejemplo de Carl de una sal de 128 bits, esto hace que la tabla sea 2 ^ 128 veces más grande, ahora eso es grande, o dicho de otro modo, ¿cuánto tiempo pasará antes de que alguien tenga un almacenamiento portátil tan grande?

La mayoría de los métodos para romper el cifrado basado en hash se basan en ataques de fuerza bruta. Un ataque de arco iris es esencialmente un ataque de diccionario más eficiente, está diseñado para usar el bajo costo del almacenamiento digital para permitir la creación de un mapa de un subconjunto sustancial de posibles contraseñas a hash y facilitar el mapeo inverso. Este tipo de ataque funciona porque muchas contraseñas tienden a ser bastante cortas o usar uno de los pocos patrones de formatos basados ​​en palabras.

Tales ataques son ineficaces en el caso en que las contraseñas contienen muchos más caracteres y no se ajustan a los formatos comunes basados ​​en palabras. Un usuario con una contraseña segura para comenzar no será vulnerable a este estilo de ataque. Desafortunadamente, muchas personas no eligen buenas contraseñas. Pero hay un compromiso, puede mejorar la contraseña de un usuario agregándole basura aleatoria. Así que ahora, en lugar de "hunter2", su contraseña podría convertirse efectivamente en "hunter2908! Fld2R75 {R7 /; 508PEzoz ^ U430", que es una contraseña mucho más segura. Sin embargo, debido a que ahora debe almacenar este componente de contraseña adicional, esto reduce la efectividad de la contraseña compuesta más segura. Como resultado, todavía hay un beneficio neto para tal esquema ya que ahora cada contraseña, incluso las débiles, ya no son vulnerables a la misma tabla hash / rainbow precalculada. En cambio, cada entrada de hash de contraseña es vulnerable solo a una tabla de hash única.

Supongamos que tiene un sitio que tiene requisitos de seguridad de contraseña débiles. Si no usa sal de contraseña en absoluto, sus valores hash son vulnerables a las tablas hash precalculadas, por lo tanto, alguien con acceso a sus valores hash tendrá acceso a las contraseñas para un gran porcentaje de sus usuarios (sin embargo, muchos utilizaron contraseñas vulnerables, lo que sería un problema). porcentaje sustancial). Si usa una sal de contraseña constante, las tablas hash precalculadas ya no son valiosas, por lo que alguien tendría que pasar el tiempo para calcular una tabla hash personalizada para esa sal, aunque podrían hacerlo de forma incremental, calculando tablas que cubren permutaciones cada vez mayores del espacio problemático. Las contraseñas más vulnerables (por ejemplo, contraseñas simples basadas en palabras, contraseñas alfanuméricas muy cortas) se descifrarían en horas o días, las contraseñas menos vulnerables se descifrarían después de algunas semanas o meses. Con el paso del tiempo, un atacante obtendría acceso a las contraseñas para un porcentaje cada vez mayor de sus usuarios. Si usa una sal única para cada contraseña, tomaría días o meses obtener acceso a cada una de esas contraseñas vulnerables.

Como puede ver, cuando pasa de no tener sal a una sal constante a una sal única, impone un aumento de varios órdenes de magnitud en el esfuerzo de descifrar contraseñas vulnerables en cada paso. Sin una sal, las contraseñas más débiles de sus usuarios son accesibles trivialmente, con una sal constante, esas contraseñas débiles son accesibles para un atacante determinado, con una sal única, el costo de acceder a las contraseñas se eleva tanto que solo el atacante más determinado podría obtener acceso a un pequeño subconjunto de contraseñas vulnerables, y luego solo a un gran costo.

Esa es precisamente la situación en la que se debe estar. Nunca puede proteger completamente a los usuarios de una mala elección de contraseña, pero puede aumentar el costo de comprometer las contraseñas de sus usuarios a un nivel que hace que comprometer incluso la contraseña de un usuario sea prohibitivamente costoso.

Un propósito de la salazón es derrotar las tablas hash precalculadas. Si alguien tiene una lista de millones de hashes precalculados, no podrán buscar $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 en su tabla a pesar de que conocen el hash y la sal. Todavía tendrán que forzarlo por fuerza bruta.

Otro propósito, como menciona Carl S, es hacer que la fuerza bruta de una lista de hashes sea más costosa. (darles todas las sales diferentes)

Ambos objetivos todavía se logran incluso si las sales son públicas.

Hasta donde yo sé, la sal pretende hacer que los ataques de diccionario sean más difíciles.

Es un hecho conocido que muchas personas usarán palabras comunes para contraseñas en lugar de cadenas aparentemente aleatorias.

Entonces, un hacker podría usar esto para su ventaja en lugar de usar solo la fuerza bruta. No buscará contraseñas como aaa, aab, aac ... sino que usará palabras y contraseñas comunes (¡como los nombres de lord of the rings!;))

Entonces, si mi contraseña es Legolas, un hacker podría intentarlo y adivinarlo con unos "pocos" intentos. Sin embargo, si le damos sal a la contraseña y se convierte en fooLegolas, el hash será diferente, por lo que el ataque del diccionario no tendrá éxito.

¡Espero que ayude!

Supongo que está utilizando PHP --- función md5 () y $ variables precedidas --- entonces, puede intentar mirar este artículo CÓMO Hacer Shadow Password Especialmente el undécimo párrafo.

Además, tiene miedo de usar algoritmos de resumen de mensajes, puede probar algoritmos de cifrado reales, como los proporcionados por el módulo mcrypt , o algoritmos de resumen de mensajes más fuertes, como los que proporcionan el módulo mhash (sha1, sha256 y otros).

Creo que un algoritmo de resumen de mensajes más fuerte es imprescindible. Se sabe que MD5 y SHA1 están teniendo problemas de colisión.