¿Por qué las sales hacen que los ataques de diccionario sean "imposibles"?


85

Actualización: tenga en cuenta que no estoy preguntando qué es una sal, qué es una tabla de arcoíris, qué es un ataque de diccionario o cuál es el propósito de una sal. Estoy preguntando: si conoce la sal y el hash de los usuarios, ¿no es bastante fácil calcular su contraseña?

Entiendo el proceso y lo implemento yo mismo en algunos de mis proyectos.

s =  random salt
storedPassword = sha1(password + s)

En la base de datos que almacena:

username | hashed_password | salt

Cada implementación de salazón que he visto agrega la sal al final de la contraseña o al comienzo:

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

Por lo tanto, un ataque de diccionario de un hacker que se precie (ja, ja) simplemente ejecutaría cada palabra clave contra las sales almacenadas en las combinaciones comunes enumeradas anteriormente.

¿Seguramente la implementación descrita anteriormente simplemente agrega otro paso para el pirata informático, sin resolver realmente el problema subyacente? ¿Qué alternativas existen para solucionar este problema o estoy entendiendo mal el problema?

Lo único que puedo pensar en hacer es tener un algoritmo de combinación secreto que une la sal y la contraseña en un patrón aleatorio, o agrega otros campos de usuario al proceso de hash, lo que significa que el hacker tendría que tener acceso a la base de datos Y el código para encajar para que un ataque de diccionario resulte fructífero. (Actualización, como se señaló en los comentarios, es mejor asumir que el pirata informático tiene acceso a toda su información, por lo que probablemente esto no sea lo mejor).

Permítanme dar un ejemplo de cómo propongo que un pirata informático piratee la base de datos de un usuario con una lista de contraseñas y hashes:

Datos de nuestra base de datos pirateada:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

Diccionario de contraseñas común:

   Common Password
   --------------
   letmein
   12345
   ...

Para cada registro de usuario, haga un bucle de las contraseñas comunes y realice un hash:

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

Espero que esto ilustre mucho mejor mi punto.

Dadas 10,000 contraseñas comunes y 10,000 registros de usuarios, necesitaríamos calcular 100,000,000 hashes para descubrir tantas contraseñas de usuarios como sea posible. Puede que tarde unas horas, pero no es realmente un problema.

Actualización sobre la teoría del craqueo

Asumiremos que somos un servidor web corrupto, que tiene acceso a una base de datos de hashes y sales SHA1, junto con su algoritmo para mezclarlos. La base de datos tiene 10.000 registros de usuarios.

Este sitio afirma poder calcular 2,300,000,000 hash SHA1 por segundo usando la GPU. (En la situación del mundo real probablemente será más lento, pero por ahora usaremos esa cifra citada).

(((95 ^ 4) / 2300000000) / 2) * 10000 = 177 segundos

Dado un rango completo de 95 caracteres ASCII imprimibles, con una longitud máxima de 4 caracteres, dividida por la tasa de cálculo (variable), dividida por 2 (asumiendo que el tiempo promedio para descubrir la contraseña requerirá en promedio el 50% de permutaciones) para 10,000 los usuarios tardarían 177 segundos en calcular todas las contraseñas de los usuarios cuya longitud sea <= 4.

Ajustémoslo un poco por realismo.

(((36 ^ 7) / 1000000000) / 2) * 10000 = 2 días

Suponiendo que no se distingue entre mayúsculas y minúsculas, con una longitud de contraseña <= 7, solo caracteres alfanuméricos, tomaría 4 días resolver los registros de 10,000 usuarios, y he reducido a la mitad la velocidad del algoritmo para reflejar la sobrecarga y las circunstancias no ideales.

Es importante reconocer que este es un ataque de fuerza bruta lineal, todos los cálculos son independientes entre sí, por lo que es una tarea perfecta para que múltiples sistemas la resuelvan. (IE es fácil de configurar 2 computadoras que ejecutan un ataque desde diferentes extremos que requerirían la mitad del tiempo de ejecución).

Dado el caso de hash recursiva de una contraseña 1000 veces para hacer esta tarea más costosa computacionalmente:

(((36 ^ 7) / 10000000000) / 2) * 1000 segundos = 10,8839117 horas

Esto representa una longitud máxima de 7 caracteres alfanuméricos, a una velocidad de ejecución inferior a la mitad de la cifra citada para un usuario .

El hash recursivo 1000 veces bloquea eficazmente un ataque general, pero los ataques dirigidos a los datos del usuario siguen siendo vulnerables.


12
El objetivo de la salazón es evitar que pueda ver la contraseña hash y ver que varios usuarios tienen el mismo hash (y, por lo tanto, la misma contraseña). Sin salar, podría usar el algoritmo hash y generar todos los hash posibles y luego hacer una búsqueda bruta de ese hash. Dado que el algoritmo nunca cambia, lo hace predecible para los atacantes, la sal lo hace mucho más difícil.
BeRecursive

25
Porque las galletas son como babosas y la sal seca la mucosa de su piel y las mata.
TED

6
@TED: Prefiero las galletas saladas. Babosas saladas, no tanto.
FrustratedWithFormsDesigner

3
@Tom - en su ejemplo, ataque. Si no hay sal, entonces el atacante puede hacer "para cada contraseña común, hash la contraseña. ¿Coincide con uno o más usuarios? Sí, tengo su contraseña" - el atacante puede atacar todas las contraseñas "en paralelo" , sin costo adicional.
Damien_The_Unbeliever

3
@Tom Gullen: solo tienes la mitad de la imagen. Sin sal, un atacante no utilizaría el método que demuestra en la "Actualización 2". Simplemente haría una búsqueda en una tabla y obtendría la contraseña en tiempo O (1) u O (log n) (siendo n el número de contraseñas candidatas). La sal es lo que evita eso y lo obliga a usar el enfoque O (n) que demuestra. Otra técnica (fortalecimiento de claves) puede hacer que cada intento en su ciclo tome un segundo completo, lo que significa que llevará 3 años realizar esas pruebas ... y con solo 10k contraseñas, es probable que no descifre ninguna contraseña en ese hora.
erickson

Respuestas:


31

Sí, solo necesita 3 días para sha1 (salt | contraseña). Es por eso que los buenos algoritmos de almacenamiento de contraseñas utilizan hash de 1000 iteraciones: necesitará 8 años.


3
+1, la respuesta más concisa y precisa hasta ahora, no sabía que esta era una opción.
Tom Gullen

Aparentemente, nunca ha realizado una evaluación comparativa de hash en su sistema. Puede hacer MUCHOS MILLONES de cálculos sha1 por segundo. 1.000 rondas no tienen sentido para un atacante. También -1 porque sha1 es una función hash rota.
torre

Aparentemente estoy usando nombres y números de la pregunta. Si alguna vez escuchaste sobre temas y claridad ... oh, es Rook. No importa.
arde

1
@Rook, 1,000 rondas significa que tomará 1,000 veces más la fuerza bruta. Me parece una buena característica.
Tom Gullen

si un atacante puede adivinar una contraseña, ¿es lo mismo para el inicio de sesión (o algo se me escapó? lol)
khaled_webdev

62

No detiene los ataques de diccionario.

Lo que hace es evitar que alguien que logra obtener una copia de su archivo de contraseña use una tabla de arco iris para averiguar cuáles son las contraseñas de los hashes.

Sin embargo, eventualmente puede ser forzado. La respuesta a esa parte es obligar a sus usuarios a no utilizar palabras del diccionario como contraseñas (requisitos mínimos de al menos un número o carácter especial, por ejemplo).

Actualización :

Debería haber mencionado esto antes, pero algunos (¿la mayoría?) Los sistemas de contraseñas usan una sal diferente para cada contraseña, probablemente almacenada con la contraseña misma. Esto hace que una sola mesa de arco iris sea inútil. Así es como funciona la biblioteca de criptas UNIX , y los sistemas operativos modernos tipo UNIX han ampliado esta biblioteca con nuevos algoritmos hash.

Sé a ciencia cierta que se agregaron soporte para SHA-256 y SHA-512 en versiones más recientes de GNU crypt.


17
+1 Salt evita que las listas precalculadas de hashes (tablas arcoíris) sean útiles. El atacante debe empezar de nuevo.
Ian Boyd

2
En PHP, puede usar las bibliotecas mcrypt o bcrypt para un mejor cifrado que md5 o sha1. Si estás atascado con md5 o sha1, deberías 'estirar', donde escribes la contraseña miles de veces antes de llegar a lo que esté almacenado en la base de datos. Esto mantiene la entropía igual, pero aumenta el tiempo para calcular el hash.
Malfist

2
@Tom Gullen, ¿qué artículos estás leyendo? ¿Expertos autoproclamados o artículos revisados ​​por pares en una revista científica?
Malfist

7
Y es el desarrollador de Joe promedio el que hace esas publicaciones de blog / ayuda sobre cómo escribir un sistema "seguro". La seguridad no es algo que pueda captar al margen, requiere un amplio conocimiento. Es injusto? Probablemente. ¿Es seguro? En un grado. Hay razones por las que hay expertos en seguridad. Pero, de nuevo, no todo tiene que ser tan seguro como Fort Knox. La mejor política aquí es utilizar un sistema prediseñado diseñado por esos expertos y modificarlo para satisfacer sus necesidades.
Malfist

3
@Michael: Con una sal más larga, debe calcular previamente todos los valores de sal posibles para que se muestre en la tabla del arco iris. El punto es que no mantiene la misma sal para todas las contraseñas, la elige al azar para cada contraseña y la almacena en la base de datos junto a la contraseña almacenada con hash y sal. Por lo tanto, un pirata informático necesitaría una entrada en la tabla del arco iris para cada posible sal de gran valor, lo que haría que la tabla fuera demasiado grande para ser factible, que es el punto.
Colin DeClue

31

Para ser más precisos, un ataque de diccionario , es decir, un ataque en el que se prueban todas las palabras de una lista exhaustiva, no se vuelve "imposible", pero se vuelve poco práctico : cada bit de sal duplica la cantidad de almacenamiento y cálculo necesarios .

Esto es diferente de los ataques de diccionario precalculados, como los ataques que involucran tablas de arco iris, donde no importa si la sal es secreta o no.

Ejemplo: con un salt de 64 bits (es decir, 8 bytes), debe verificar 2 64 combinaciones de contraseña adicionales en su ataque de diccionario. Con un diccionario que contiene 200.000 palabras tendrás que hacer

200 000 * 2 64 = 3,69 * 10 24

pruebas en el peor de los casos, en lugar de 200.000 pruebas sin sal.

Un beneficio adicional de usar salt es que un atacante no puede precalcular los hashes de contraseña de su diccionario. Simplemente tomaría demasiado tiempo y / o espacio.

Actualizar

Su actualización asume que un atacante ya conoce la sal (o la ha robado). Esta es, por supuesto, una situación diferente. Aún así, el atacante no puede usar una tabla de arco iris precalculada. Lo que importa mucho aquí es la velocidad de la función hash. Para que un ataque no sea práctico, la función hash debe ser lenta. MD5 o SHA no son buenos candidatos aquí porque están diseñados para ser rápidos, los mejores candidatos para algoritmos hash son Blowfish o algunas variaciones de este.

Actualización 2

Una buena lectura sobre el tema de la seguridad de los hashes de contraseña en general (va mucho más allá de la pregunta original pero sigue siendo interesante):

Suficiente con las tablas del arco iris: lo que necesita saber sobre los esquemas de contraseña segura

Corolario del artículo: Use hash salados creados con bcrypt (basado en Blowfish) o Eksblowfish que le permite usar un tiempo de configuración configurable para hacer que el hash sea lento.


4
@Tom Gullen: incluso con políticas de contraseñas sólidas y razonables, es probable que un diccionario de cientos de millones o unos pocos miles de millones de candidatos obtenga algunos resultados, porque no todas las contraseñas son igualmente probables (porque la gente usa mnemónicos, en lugar de RNG, para elegirlas) . Un diccionario de ese tamaño es precalculable sobre sistemas de productos básicos si no se usa sal. Si se usa sal, el atacante tiene que volver a calcular los hash cada vez, y si se realizan suficientes iteraciones del hash, la velocidad de ataque del atacante puede reducirse a unos pocos intentos por segundo.
erickson

3
-1 de mí: ser mantenido en secreto no es totalmente el punto de las sales. De todos modos, los necesita accesibles para verificar las contraseñas, por lo que cualquier intento de mantenerlas en secreto probablemente hará que el sistema sea más vulnerable a través de una mayor complejidad en lugar de tener éxito.
Michael Borgwardt

2
@ 0xA3: de nuevo: ser desconocido para un atacante no es el punto de mira . Su máquina necesita acceder a ella de alguna manera, por lo que un atacante que irrumpe en la máquina también puede obtenerla. Cualquier escenario en el que el atacante no conozca la sal es una pista falsa.
Michael Borgwardt

1
Creo que vale la pena mencionar que el artículo vinculado describe mal las tablas de arco iris. Lo que describe es un simple diccionario adjunto. Las tablas de arco iris son realmente bastante diferentes (y algo más complejas). Hay una explicación bastante decente de cómo funcionan realmente las tablas de arco iris en: kestas.kuliukas.com/RainbowTables
Jerry Coffin

3
-1 para "Por supuesto que la sal debe mantenerse en secreto". Si un atacante tiene acceso a los hashes de su contraseña, también tendrá sus sales; lo que necesita son las sales por usuario , no la seguridad a través de la oscuridad de una sal "oculta".
snemarch

17

Un diccionario es una estructura donde los valores se indexan por claves. En el caso de un ataque de diccionario precalculado, cada clave es un hash y el valor correspondiente es una contraseña que da como resultado el hash. Con un diccionario precalculado en la mano, un atacante puede buscar "instantáneamente" una contraseña que producirá el hash necesario para iniciar sesión.

Con la sal, el espacio necesario para almacenar el diccionario crece rápidamente ... tan rápidamente que tratar de precalcular un diccionario de contraseñas pronto se vuelve inútil.

Las mejores sales se eligen al azar de un generador criptográfico de números aleatorios. Ocho bytes es un tamaño práctico y más de 16 bytes no sirve para nada.


Salt hace mucho más que "hacer más irritante el trabajo de un atacante". Elimina toda una clase de ataque: el uso de diccionarios precalculados.

Otro elemento es necesario para asegurar completamente las contraseñas, y es el "fortalecimiento de claves". Una ronda de SHA-1 no es lo suficientemente buena: un algoritmo de hash de contraseña seguro debería ser muy lento computacionalmente.

Mucha gente usa PBKDF2, una función de derivación de claves, que retroalimenta los resultados a la función hash miles de veces. El algoritmo "bcrypt" es similar, utilizando una derivación de clave iterativa que es lenta.

Cuando la operación de hash es muy lenta, una tabla precalculada se vuelve cada vez más deseable para un atacante. Pero la sal adecuada derrota ese enfoque.


Comentarios

A continuación se muestran los comentarios que hice sobre la pregunta.


Sin sal, un atacante no usaría el método demostrado en la "Actualización 2". Simplemente haría una búsqueda en una tabla precalculada y obtendría la contraseña en tiempo O (1) u O (log n) (siendo n el número de contraseñas candidatas). Salt es lo que lo impide y lo obliga a utilizar el enfoque O (n) que se muestra en la "Actualización 2".

Una vez reducido a un ataque O (n), tenemos que considerar cuánto tiempo toma cada intento. El fortalecimiento de claves puede hacer que cada intento en el ciclo tome un segundo completo, lo que significa que el tiempo necesario para probar 10k contraseñas en 10k usuarios se extenderá de 3 días a 3 años ... y con solo 10k contraseñas, es probable que no descifre cero contraseñas en ese tiempo.

Debe considerar que un atacante va a utilizar las herramientas más rápidas que pueda, no PHP, por lo que miles de iteraciones, en lugar de 100, serían un buen parámetro para el fortalecimiento de claves. Debería llevar una gran fracción de segundo calcular el hash de una sola contraseña.

El fortalecimiento de claves es parte de los algoritmos estándar de derivación de claves PBKDF1 y PBKDF2, de PKCS # 5, que son excelentes algoritmos de ofuscación de contraseñas (la "clave derivada" es el "hash").

Muchos usuarios de StackOverflow se refieren a este artículo porque fue una respuesta a la publicación de Jeff Atwood sobre los peligros de las tablas de arco iris. No es mi artículo favorito, pero trata estos conceptos con más detalle.


Por supuesto, asume que el atacante lo tiene todo: sal, hash, nombre de usuario. Suponga que el atacante es un empleado corrupto de la empresa de alojamiento que arrojó la tabla de usuarios en su sitio de fans myprettypony.com. Está intentando recuperar estas contraseñas porque se dará la vuelta y verá si sus fans de pony usaron la misma contraseña en sus cuentas de citibank.com.

Con un esquema de contraseñas bien diseñado, será imposible para este tipo recuperar las contraseñas.


1
Creo que por "ataque de diccionario", Tom se refiere a probar contraseñas débiles conocidas (es decir, directamente de un diccionario de lenguaje humano), no tablas de texto sin formato hash precalculadas; esto también es lo que primero pienso cuando leo "diccionario" en este contexto.
Michael Borgwardt

@Michael Borgwardt: Estoy de acuerdo, @erickson se refiere a ataques de diccionario precalculados.
Dirk Vollmar

1
Salt detiene los ataques de diccionario precalculados. El fortalecimiento de claves detiene los ataques de diccionario. Ambos deben usarse juntos para la autenticación de contraseña segura.
erickson

Me refiero a tablas en inglés simple, sí. Los objetivos de interrogación para abordar el problema de cómo detener un pirata informático que trabaja a cabo todas las combinaciones posibles de valores hash para cada cuenta de usuario
Tom Gullen

7

El objetivo de la salazón es evitar la amortización del esfuerzo del atacante.

Sin sal, una única tabla de entradas de contraseña hash precalculadas (por ejemplo, MD5 de todas las cadenas alfanuméricas de 5 caracteres, fáciles de encontrar en línea) se puede utilizar en cada usuario en todas las bases de datos del mundo.

Con una sal específica del sitio, el atacante tiene que calcular la tabla él mismo y luego puede usarla en todos los usuarios del sitio.

Con una sal por usuario, el atacante tiene que realizar este esfuerzo para cada usuario por separado.

Por supuesto, esto no hace mucho para proteger contraseñas realmente débiles directamente de un diccionario, pero protege contraseñas razonablemente fuertes contra esta amortización.


1
Respuesta breve y precisa: vale la pena agregar que sin sal o con sal en todo el sitio, puede detectar fácilmente a los usuarios con la misma contraseña y solo necesitará usar una de fuerza bruta. Con las sales por usuario, no puede hacer eso.
snemarch

6

Además, un punto importante más, el uso de una sal específica de USUARIO evita la detección de dos usuarios con la MISMA contraseña: sus hashes coincidirían. Por eso muchas veces el hash es hash (salt + usuario + contraseña)

Si intenta mantener el hash en secreto, el atacante tampoco podrá verificar los hash.

Editar: acabo de notar que el punto principal se hizo en un comentario anterior.


1
Debe editar para especificar la sal por usuario; los sitios que usan un salt para todo el sitio aún le permitirán detectar contraseñas idénticas.
snemarch

@snemarch - Sí, ¡muchas gracias por esta importante distinción!
Dominik Weber

5

Las sales se implementan para prevenir ataques de mesa arcoíris. Una tabla de arco iris es una lista de hashes precalculados, lo que hace que traducir un hash a su frase sea mucho más simple. Debe comprender que la salazón no es efectiva como una prevención moderna para descifrar una contraseña a menos que tengamos un algoritmo hash moderno.

Entonces, digamos que estamos trabajando con SHA1, aprovechando los exploits recientes descubiertos con este algoritmo, y digamos que tenemos una computadora funcionando a 1,000,000 de hashes / segundo, se necesitarían 5.3 millones de millones de años para encontrar una colisión , así que sí php puede trabajar 300 por segundo, gran woop, realmente no importa. La razón por la que saltamos es porque si alguien se molestara en generar todas las frases comunes del diccionario (2 ^ 160 personas, bienvenidos a las hazañas de la era 2007).

Así que aquí hay una base de datos real, con 2 usuarios que uso para fines de prueba y administración.

RegistrationTime        UserName        UserPass    
1280185359.365591       briang      a50b63e927b3aebfc20cd783e0fc5321b0e5e8b5
1281546174.065087       test        5872548f2abfef8cb729cac14bc979462798d023

De hecho, el esquema de salazón es su sha1 (tiempo de registro + nombre de usuario). Adelante, dime mi contraseña, estas son contraseñas reales en producción. Incluso puede sentarse allí y hacer una lista de palabras en php. Enloquecer.

No estoy loco, solo sé que esto es seguro. Por diversión, la contraseña de prueba es test. sha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023

Debería generar una tabla de arco iris completa con perpendicular solo27662aee8eee1cb5ab4917b09bdba31d091ab732 para este usuario. Eso significa que puedo permitir que mis contraseñas no se vean comprometidas por una sola tabla de arco iris, el pirata informático necesita generar una tabla de arco iris completa para 27662aee8eee1cb5ab4917b09bdba31d091ab732 para la prueba, y nuevamente f3f7735311217529f2e020468004a2aa5b3dee7f para briang. Piense en los 5,3 millones de millones de millones de años para todos los valores hash. Piense en el tamaño de almacenar solo los 2 ^ 80 hashes (eso es más de 20 yottabytes ), no va a suceder.

No confunda la salazón como un medio para hacer que un hash sea algo que nunca podrá decodificar, es un medio para evitar que una tabla de arco iris traduzca todas sus contraseñas de usuario. Es imposible a este nivel de tecnología.


Entiendo lo que es una mesa arcoíris, pero no captas el sentido de mi pregunta. Si me proporcionó su algoritmo de salazón, una contraseña con hash y la sal, entonces sí, probablemente podría decirle cuál era su contraseña en unos minutos.
Tom Gullen

¿Pon tu dinero dónde está tu boca?
Incógnito

Claro, pero me acabas de decir cuál es la contraseña en tu ejemplo, dame una contraseña sal, hash y cómo combinas la contraseña salt + (no recursiva) y siempre que la contraseña <= 5 caracteres alfanuméricos en minúscula (sin espacios en blanco / caracteres especiales) Te haré saber qué hay en este cuadro. Si quieres que le ponga dinero como sugieres, avísame, aunque mi comentario de unos minutos es probablemente una gran subestimación, pero en unas horas sí.
Tom Gullen

1
Quizás segundos en realidad, consulte golubev.com/hashgpu.htm que usa GPU para calcular como se indica "2300M / s SHA1 hashes por segundo". Con una gama completa de 95 caracteres ASCII que van de 1 a 6 caracteres, podemos descifrarlo en <6 minutos. Si solo tenemos caracteres alfanuméricos en minúscula, hasta 8 caracteres de duración <25 minutos. Con una base de datos de 10,000 registros de usuario, podríamos encontrar las contraseñas ASCII completas de 4 caracteres en <200 segundos ((((95 ^ 4) / 2300000000) / 2) * 10000). (Más gastos generales de los indicados, y las velocidades de GPU cotizadas son probablemente situaciones ideales).
Tom Gullen

Sí, la sal no le impide poder usar la fuerza bruta de esa contraseña. Le dificulta generar el ((10 ^ 5) * (94 ^ 10)) = 10 ^ 24 si los usuarios tienen contraseñas de alrededor de 10 caracteres, que es mucho más difícil que el 10 ^ 19 sin hash. Nuevamente, no es para dificultar la tarea de romper una contraseña, es para hacer que sea imposible romper todas las contraseñas con una tabla de arco iris preprocesada. (y verifique mis matemáticas aquí, pero creo que 10 ^ 25/2300000000/60/60/24/365/1000 = 137869 ~ milinea para la contraseña de todos). Si queremos contraseñas más seguras, no las agregamos, utilizamos cosas como el intercambio de claves Diffie-Hellman.
Incógnito

3

La idea detrás del ataque de diccionario es que tomas un hash y encuentras la contraseña, a partir de la cual se calculó este hash, sin cálculo de hash. Ahora haga lo mismo con la contraseña salada, no puede.

No usar un salt hace que la búsqueda de contraseñas sea tan fácil como buscar en la base de datos. Agregar una sal hace que el atacante realice un cálculo hash de todas las contraseñas posibles (incluso para adjuntar un diccionario, esto aumenta significativamente el tiempo de ataque).


En el escenario del OP, el atacante tiene las sales de la base de datos y tendrá que probar todas las sales con cada entrada en el "diccionario". ...Yo creo que.
FrustratedWithFormsDesigner

2

En términos más simples: sin sal, cada contraseña candidata solo necesita ser hash una vez para compararla con cada usuario, en cualquier lugar del "universo conocido" (colección de bases de datos comprometidas), cuya contraseña se hash mediante el mismo algoritmo. Con la salazón, si el número de posibles valores de sal excede sustancialmente el número de usuarios en el "universo conocido", cada contraseña candidata debe tener un hash por separado para cada usuario con el que se probará.


2

En pocas palabras, la salazón no evita el ataque de un hash (fuerza bruta o diccionario), solo lo hace más difícil; el atacante necesitará encontrar el algoritmo de salazón (que si se implementa correctamente hará uso de más iteraciones) o fuerza bruta el algoritmo, que a menos que sea muy simple, es casi imposible. La salazón también descarta casi por completo la opción de búsquedas de tablas de arco iris ...


1

Salt hace que los ataques de tablas de Rainbow sean mucho más difíciles, ya que hace que sea mucho más difícil descifrar un hash de contraseña único. Imagina que tienes una contraseña horrible de solo el número 1. Un ataque de tabla de arco iris rompería esto de inmediato.

Ahora imagine que cada contraseña en la base de datos tiene un valor aleatorio largo de muchos caracteres aleatorios. Ahora su pésima contraseña de "1" se almacena en la base de datos como un hash de 1 más un montón de caracteres aleatorios (la sal), por lo que en este ejemplo la tabla del arco iris debe tener el hash de algo como: 1.

Entonces, asumiendo que su sal es algo seguro y aleatorio, digamos ()% ISLDGHASKLU ( % #% #, la tabla de arco iris del hacker debería tener una entrada para 1 * ()% ISLDGHASKLU (*% #% #. Ahora usando una tabla de arco iris incluso esta simple contraseña ya no es práctica.


Consulte la actualización n. ° 2, simplemente tendría contraseñas sin procesar y calcularía todos los valores hash con las sales para cada registro de usuario.
Tom Gullen

2
Seguro Tom, estoy de acuerdo, pero el caso es que el hacker tiene que hacer ese desagradable proceso que lleva mucho tiempo una vez por cada contraseña si se usa sal. Por lo tanto, la sal dificulta el uso de una mesa arcoíris.
Cory House

3
@Tom Gullen: generar tablas arcoíris saladas solo es factible si se utilizan sales en todo el sitio; la salazón por usuario hace que los ataques de mesa arcoíris sean prácticamente inútiles.
snemarch
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.