¿Cómo ayuda password salt contra un ataque de mesa rainbow?

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 utilice de la siguiente manera:

$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 con la sal.

Usted siempre tiene que guardar la sal con la contraseña, porque con el fin de validar lo que el usuario introdujo en su base de datos de contraseñas, usted tiene que combinar la entrada con la sal, hash y compararlo con el hash almacenado.

Seguridad del hash

Ahora alguien con una tabla rainbow podría invertir el hash y llegar a la entrada "foobar".

[...]

Desde el hash inverso de te5SBM.7C25fFDu6bIRbX es conocido por contener "foo".

No es posible invertir el hash como tal (en teoría, al menos). El hash de "foo" y el hash de "saltfoo" tiene 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 rainbow con las contraseñas comunes y luego "actualizarla" con un poco de sal. Hay que tener en cuenta la sal desde el principio.

Esta es la razón por la que necesitas una mesa rainbow en primer lugar. Porque no puedes conseguir a la contraseña del hash, precomputa todos los hashes de las contraseñas más probables utilizadas y luego compara sus hashes con sus hashes.

Calidad de la sal

Pero digamos $salt=foo

"foo" sería una extremadamente 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 en el sistema. Esto significa que el atacante tiene que atacar cada contraseña individualmente en lugar de tener la esperanza de que uno de los hashes coincida con uno de los valores en su base de datos.

El ataque

Si un hacker de alguna manera pudo poner sus manos en este archivo, no veo para qué sirve la sal,

Un ataque de tabla rainbow siempre necesita /etc/passwd (o cualquier base de datos de contraseñas que se use), o bien, ¿cómo compararía los hashes en la tabla rainbow con los hashes del las contraseñas?

En cuanto al propósito: digamos que el atacante quiere construir una tabla rainbow para 100,000 palabras en inglés de uso común y contraseñas típicas (piense en "secreto"). Sin sal tendría que precomputar 100.000 hashes. Incluso con la sal tradicional de UNIX 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 de hashes... toda una mejora.

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 mesas Rainbow a menudo se construyen con un conjunto de caracteres especial en mente, y no siempre incluyen todas las combinaciones posibles (aunque sí pueden).

Así que un buen valor de sal sería un entero aleatorio de 128 bits o más largo. Esto es lo que hace que los ataques rainbow-table fallen. Al usar un valor de sal diferente para cada contraseña almacenada, también se asegura de que se cree una tabla rainbow para un valor de sal en particular (como podría ser el caso si usted es un sistema popular con un solo valor de sal) no le da acceso a todas las contraseñas a la vez.

Otra gran pregunta, con muchas respuestas muy reflexivas + + 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, está prácticamente garantizando que dos usuarios que eligieron la misma contraseña producirán diferentes hashes.

¿Por qué es esto importante?

Imagine la base de datos de contraseñas de una gran empresa de software en el noroeste de EE. Supongamos que contiene 30.000 entradas, de las cuales 500 tienen la contraseña bluescreen . 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 están saladas, el hacker puede encontrar el valor hash en la base de datos, luego simplemente pattern-match para obtener acceso a las otras 499 cuentas.

Salar las contraseñas asegura que cada una de las 500 cuentas tenga una única (salt + password), generando un hash diferente para cada una de ellas, y de este modo reducir la brecha a una sola cuenta. Y esperemos, contra toda probabilidad, que cualquier usuario lo suficientemente ingenuo como para escribir una contraseña de texto plano en un mensaje de correo electrónico no tenga acceso a la API indocumentada para el próximo sistema operativo.

Estaba buscando un buen método para aplicar sales y encontré este excelente artículo con un 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 aleatoria larga usando un CSPRNG.
• Anteponga la sal a la contraseña y hash con una estándar función hash criptográfica como SHA256.
• Guarde tanto la sal como el hash en el registro de la base de datos del usuario.

Para Validar una Contraseña:

• Recupera la sal y el hash del usuario de la base de datos.
• Anteponga la sal a la contraseña dada y hash usando la misma función hash.
• Compare el hash de la contraseña dada con el hash de la base de datos. Si coincide, la contraseña es correcta. De lo contrario, el la contraseña es incorrecta.

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

Su ejemplo de usar 'foo' como una sal podría hacer que la tabla 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 2^128 veces más grande-ahora que es grande - o dicho de otra manera, ¿cuánto tiempo antes de que alguien tenga 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 arco iris es esencialmente un ataque de diccionario más eficiente, está diseñado para utilizar 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 algunos patrones de formatos basados en palabras.

Tales ataques son ineficaces en el caso de que las contraseñas contengan muchos más caracteres y no se ajusten a los formatos comunes basados en palabras. Un usuario con una contraseña segura para empezar no será vulnerable a este estilo de ataque. Desafortunadamente, muchas personas no eligen buenas contraseñas. Pero hay un compromiso, puedes 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" hunter2908!fld2R75{R7/; 508PEzoz^U430", que es una contraseña mucho más fuerte. Obstante, 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 hash / rainbow pre-calculada. En su lugar, cada entrada de hash de contraseña es vulnerable solo a una tabla hash única.

Supongamos que tiene un sitio que tiene requisitos de seguridad de contraseña débiles. Si no utiliza contraseña salt en todos sus hashes son vulnerables a las tablas hash pre-calculadas, alguien con acceso a sus hashes tendría acceso a las contraseñas para un gran porcentaje de sus usuarios (sin embargo, muchos utilizan contraseñas vulnerables, que sería un porcentaje sustancial). Si utiliza una sal de contraseña constante, las tablas hash pre-calculadas ya no son valiosas, por lo que alguien tendría que pasar el tiempo para calcular una tabla hash personalizada para esa sal, podrían hacerlo de forma incremental, sin embargo, 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 unas semanas o meses. A medida que pasa el tiempo, un atacante obtendría acceso a contraseñas para un porcentaje cada vez mayor de sus usuarios. Si usa una sal única para cada contraseña, tardaría días o meses en obtener acceso a cada una de esas personas vulnerables contraseña.

Como puede ver, cuando se pasa de una sal sin sal a una sal constante a una sal única, se impone un aumento de varios órdenes de magnitud en el esfuerzo por descifrar contraseñas vulnerables en cada paso. Sin una sal, las contraseñas más débiles de sus usuarios son trivialmente accesibles, 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 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.

Que es precisamente la situación para estar en. Nunca puede proteger completamente a los usuarios de una mala elección de contraseñas, 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.

Uno de los propósitos de la salazón es derrotar las tablas hash precalculadas. Si alguien tiene una lista de millones de hashes pre-calculados, no van a ser capaces de buscar $1 fo foo te te5SBM.7C25fFDu6bIRbX1 en su mesa a pesar de que saben el hachís y la sal. Todavía tendrán que forzarlo.

Otro propósito, como menciona Carl S, es encarecer el forzamiento bruto de una lista de hashes. (dales todas las sales diferentes)

Ambos objetivos aún se cumplen incluso si las sales son públicas.

Por lo que sé, la sal tiene la intención de hacer que los ataques del 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 a su favor en lugar de usar solo la fuerza bruta. No buscará contraseñas como aaa, aab, aac... pero en lugar de usar palabras y contraseñas comunes (como los nombres de señor de los anillos! ;) )

Así que si mi contraseña es Legolas un hacker podría intentar eso y adivinar con unos "pocos" intentos. Sin embargo, si salamos la contraseña y se convierte en fooLegolas el hash será diferente, por lo que el ataque del diccionario no tendrá éxito.

Espero que eso ayude!

Asumo que estás usando la función PHP --- md5 (), y variables preceded variables --- entonces, puedes intentar buscar este artículo Shadow Password HOWTO 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 ese algoritmo de resumen de mensajes más fuerte es una necesidad. Se sabe que MD5 y SHA1 están teniendo problemas de colisión.