hash - tablas - ¿Cómo ayuda la sal de contraseña contra un ataque de mesa arco iris?

tabla arcoiris hash (10)

Tengo algunos problemas para entender el propósito de saltear una contraseña. Tengo entendido que el uso principal es obstaculizar un ataque a 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 como la siguiente:

$hash = md5($salt.$password)

El razonamiento es que el hash ahora se asigna no a la contraseña original, sino a una combinación de la contraseña y la sal. Pero diga $salt=foo y $password=bar y $hash=3858f62230ac3c915f300c664312c63f . Ahora, alguien con una tabla de arco iris 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 para obtener la contraseña, pero no mucho más.

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

Gracias por cualquier luz que alguien pueda arrojar sobre esto.

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

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

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

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

Para almacenar una contraseña:
Generar una sal aleatoria larga utilizando un CSPRNG.
Preponga el salt a la contraseña y haga un hash con una función de hash criptográfica estándar como SHA256.
Guarde tanto el salt como el hash en el registro de la base de datos del usuario.
Para validar una contraseña:
Recuperar la sal y el hash del usuario de la base de datos.
Preponga el salt a la contraseña dada y haga un hash usando la misma función hash.
Compara 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 idea con la sal es hacer que sea mucho más difícil de adivinar con fuerza bruta que una contraseña normal basada en caracteres. Las tablas del arco iris a menudo se construyen con un conjunto de caracteres especiales 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 fracasar los ataques de mesa arco iris. Al utilizar 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 solo valor de sal) no le da acceso a todos contraseñas a la vez.

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 hashes y facilitar el mapeo inverso. Este tipo de ataque funciona porque muchas contraseñas tienden a ser bastante cortas o usan uno de los pocos patrones de formatos basados en palabras.

Dichos ataques son ineficaces en el caso de que las contraseñas contengan muchos más caracteres y no se ajusten a los formatos basados en palabras comunes. Un usuario con una contraseña segura para comenzar no será vulnerable a este tipo de ataque. Desafortunadamente, muchas personas no escogen 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 tiene que almacenar este componente de contraseña adicional, esto reduce la efectividad de la contraseña compuesta más fuerte. 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 de hash / arco iris pre-computada. En su lugar, cada entrada de hash de contraseña es vulnerable solo a una tabla hash única.

Digamos que tienes un sitio que tiene requisitos de seguridad de contraseña débiles. Si no utiliza sal de contraseña, todos los hashes son vulnerables a las tablas hash precalculadas, por lo tanto, alguien con acceso a sus hashes tendrá acceso a las contraseñas para un gran porcentaje de sus usuarios (sin embargo, muchas utilizan contraseñas vulnerables, lo que sería una porcentaje sustancial). Si usa una contraseña de sal constante, las tablas hash precalculadas ya no son valiosas, por lo que alguien tendría que dedicar tiempo a calcular una tabla hash personalizada para esa sal, aunque podrían hacerlo de manera incremental, las tablas de computación que cubren permutaciones cada vez mayores. del espacio problema. 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 unas pocas semanas o meses. A medida que pasa el tiempo, un atacante obtendría acceso a las contraseñas para un porcentaje cada vez mayor de sus usuarios. Si usa un salt único para cada contraseña, tomará días o meses para obtener acceso a cada una de esas contraseñas vulnerables.

Como puede ver, cuando pasa de no 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 de manera trivial, 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 es tan alto 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.

Cuál 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.

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

Tu 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 un sal de 128 bits, esto hace que la tabla sea 2 ^ 128 veces más grande, ahora que es grande, o dicho de otra manera, ¿cuánto tiempo antes de que alguien tenga un almacenamiento portátil tan grande?

Las otras respuestas no parecen abordar sus malentendidos del tema, así que aquí van:

Dos usos diferentes de la sal.

He visto muchos tutoriales que sugieren que la sal se use como la siguiente:
$hash = md5($salt.$password)

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

Siempre debe almacenar el salt con la contraseña, ya que para validar lo que el usuario ingresó en su base de datos de contraseñas, debe combinar la entrada con el salt, hacer un hash y compararla con el hash almacenado.

Seguridad del hash

Ahora, alguien con una tabla de arco iris podría revertir el hash y generar la entrada "foobar".
[...]
ya que el hash inverso de te5SBM.7C25fFDu6bIRbX es conocido por contener "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 criptográfica de hash 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. Hay que tener en cuenta la sal desde el principio.

Esta es la razón principal por la que necesitas una tabla de arco iris en primer lugar. Debido a que no puede obtener la contraseña desde el hash, debe calcular previamente todos los hashes de las contraseñas más utilizadas y luego compararlos con sus hashes.

Calidad de la sal.

Pero digamos $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 hacker de alguna manera pudiera tener en sus manos este archivo, no veo para qué sirve la sal,

Un ataque de tabla arco iris siempre necesita /etc/passwd (o la base de datos de contraseñas que se use), o ¿cómo compararía los hashes en la tabla de arco iris con los hashes 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 calcular de antemano 100.000 hashes. Incluso con la sal tradicional de UNIX de 2 caracteres (cada una es una de las 64 opciones: [a–zA–Z0–9./] ) tendría que computar y almacenar 4,096,000,000 hashes ... una gran mejora.

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 un salt aleatorio a cada contraseña, prácticamente se garantiza que los 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 pantalla azul de contraseña. Supongamos además que un pirata informático logra obtener esta contraseña, por ejemplo, leyéndolo 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 de hash en la base de datos, luego simplemente haga una comparación de patrones para obtener acceso a las otras 499 cuentas.

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

Que yo sepa, la sal tiene la intención de 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.

Por lo tanto, un hacker podría usar esto para su ventaja en lugar de usar solo 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 intentar eso y adivinarlo con "pocos" intentos. Sin embargo, si eliminamos 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 la función PHP --- md5 () y $ variables precedidas --- luego, puede intentar buscar en este artículo CÓMO de contraseña secreta, especialmente el párrafo 11.

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 digestión de mensajes más fuerte es una necesidad. Se sabe que MD5 y SHA1 tienen problemas de colisión.

Una sal pública no dificultará los ataques de diccionario al descifrar una sola contraseña. Como ha señalado, el atacante tiene acceso tanto a la contraseña con hash como a la sal, por lo que cuando ejecuta el ataque del diccionario, simplemente puede usar la sal conocida cuando intenta 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 hace imposible usar una tabla de arco iris.

Para entender el primero, imagine un solo archivo de contraseña que contenga cientos de nombres de usuario y contraseñas. Sin un salt, podría calcular "md5 (intento [0])", y luego escanear el archivo para ver si ese hash aparece en alguna parte. Si hay sales presentes, 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 n veces más trabajo que hacer, donde n es el número de nombres de usuario y contraseñas que contiene el archivo.

Para entender el segundo, debes entender qué es una tabla de arco iris. Una tabla de arco iris es una gran lista de hashes precalculados para las contraseñas de uso común. Imagina nuevamente el archivo de contraseñas sin sales. Todo lo que tengo que hacer es revisar cada línea del archivo, extraer la contraseña de hash 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 (que probablemente sea), esto acelerará considerablemente el resquebrajamiento del archivo.

Pero si el archivo de contraseñas está en formato salado, entonces la tabla del arco iris tendría que contener "salt. Password" 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 usadas (la tabla del arco iris), pero no voy a tener cosas como "jX95psDZhello" o "LPgB0sdgxfoobar" o "dZVUABJtqwerty" precalculado. Eso haría la mesa del arco iris prohibitivamente grande.

Por lo tanto, la sal reduce al atacante de nuevo a un cálculo por fila por intento, que, cuando se combina con una contraseña suficientemente larga y suficientemente aleatoria, es (en términos generales) imposible de encontrar.

Uno de los propósitos de la salazón es derrotar tablas hash precomputadas. Si alguien tiene una lista de millones de hash pre-computados, 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 hacerlo por fuerza bruta.

Otro propósito, como menciona Carl S, es hacer más costoso el proceso de forzar una lista de hashes. (dales todas las sales diferentes)

Ambos objetivos se siguen cumpliendo incluso si las sales son públicas.