¿Por qué Salt no hubiera impedido que las contraseñas de LinkedIn se rompieran?

Krebs continúa con esta pregunta, y Ptacek aclara lo que quería decir:

  

BK: está bien. Entonces, si la debilidad no es con la fuerza del algoritmo criptográfico, y no con la falta de sal agregada a las contraseñas con hash, ¿cuál es la respuesta?

     

Ptacek: en el caso de LinkedIn, y con muchos otros sitios, el problema es que están utilizando el tipo de algoritmo incorrecto. Usan un hash criptográfico, cuando necesitan usar un hash de contraseña.

En los siguientes párrafos, él también explica las razones para ello. En resumen, SHA1, con o sin sal, es demasiado rápido para usarlo como un hash de contraseña. Es tan rápido, que cuando se calcula utilizando una GPU o algo similar, puede hacer fuerza bruta 10s de miles de hashes por segundo. Como se explica más adelante en la entrevista, LinkedIn debería haber estado usando bcrypt , que es un hash adaptativo que habría ralentizado el tiempo de fuerza bruta en el orden de 10 segundos de hashes por segundo.

Primero veamos la cuestión de la sal y luego el problema de la velocidad:

Sal, ataques de diccionario y tablas de arco iris

Una sal ayuda enormemente contra los ataques de diccionario en el caso común de que un atacante obtenga acceso a más de un hash de contraseña.

Sin una sal, un atacante ordenará todos los hashes. Hasheará la primera palabra del diccionario de contraseñas y verificará si el hash calculado está en su lista ordenada de hashes robados . Con un poco de suerte, ya tuvo acceso a varias cuentas.

Pero con un salt , tiene que atacar cada cuenta por separado .

Las tablas de arco iris son solo un caso especial de ataques de diccionario, en el sentido de que se realizaron antes del ataque y están listos para usar.

Es importante tener en cuenta que: pegar una cadena aleatoria constante a todas las contraseñas hará que las tablas arcoiris precreadas sean inútiles. Pero sigue siendo una mala idea debido al problema del paralelismo descrito anteriormente.

Velocidad, algoritmos para documentos frente a contraseñas

Además de no usar un salt, LinkedIn utilizó un algoritmo hash que es muy rápido y puede ejecutarse en hardware especial para obtener aún más velocidad. Este hardware especial no es exótico sino que forma parte de las tarjetas gráficas .

Robert David Graham publicó los detalles de su trabajo de craqueo , incluido el rendimiento datos:

  

2 mil millones por segundo utilizando la Radeon HD 7970. Una contraseña de 6 [caracteres] [en] 500 segundos [...] con fuerza bruta.

El caso de uso original de los algoritmos hash era firmar documentos. Por lo tanto, ser rápido era un objetivo de diseño.

Los algoritmos hash modernos para contraseñas están diseñados para ser relativamente lentos . Una forma sencilla de hacerlos más lentos es usar la función hash repetidamente. ShaCrypt y BCrypt son tales algoritmos. Prestan especial atención para evitar el procesamiento paralelo y resistir los ataques de pre-imagen en una sola ronda.

Scrypt lleva esto un paso más allá: además de ser lento, requiere mucha memoria (por ejemplo, 16 MB para la configuración predeterminada). El hardware especializado generalmente solo tiene acceso a aproximadamente 1 KB de memoria interna rápida. El acceso a la memoria central es lento. Por lo tanto, construir un cracker scrypt rápido en hardware se encarece muy rápidamente.

Usted tiene razón, sin embargo, eso no cambia el hecho de que es esencial usar una sal. En este caso, los atacantes se apoderaron de las contraseñas con hash, por lo que podrían usar una tabla de arco iris o iniciar un ataque de fuerza bruta o diccionario.

• Una tabla de arco iris te dará todas las contraseñas (hasta el tamaño y la complejidad de la tabla) en un espacio de tiempo muy corto.

• Del mismo modo, un ataque de diccionario te dará las contraseñas que están en los diccionarios.

• Brute forcing te dará las contraseñas cortas y sencillas rápidamente, pero el tiempo que se tarda en obtener las más largas rápidamente se vuelve tan prohibitivo que los usuarios con contraseñas largas siguen siendo relativamente seguros.

Por lo tanto, una sal elimina el primer conjunto de posibilidades, obligando a los atacantes a usar soluciones de diccionario y fuerza bruta, lo que hace que los usuarios estén más seguros.

Lo que hace un salt es que deja inútiles las tablas arco iris, lo que frena los intentos de fuerza bruta en la contraseña.

Definición de tabla de arco iris:

  

Una tabla de arco iris es una tabla precomputada para revertir criptografía   Funciones hash, generalmente para craquear las contraseñas de las contraseñas.

Sin un salt, un atacante podría usar fácilmente una tabla de arco iris pregenerada que contiene millones de contraseñas y su equivalente de hash y compararla con la contraseña.

Con un salt, cada contraseña requiere que el atacante genere una tabla de arco iris completamente nueva.

No tiene impacto en los ataques de diccionario: las contraseñas fáciles y obvias basadas en diccionarios, como las contraseñas, se descifrarán fácilmente con o sin la sal.

Sin embargo, DEBE usarse una sal. El craqueo de contraseñas se trata de tiempo / esfuerzo. Ninguna contraseña / hash es invencible. Se trata de obligar al atacante a pasar más tiempo del que está dispuesto a gastar en sus tablas de contraseñas.

Las sales previenen el paralelismo. El paralelismo es genérico en todo el continuo espacio-tiempo; con esto, quiero decir que se puede aplicar por espacio y y por tiempo :

• El paralelismo en el espacio es cuando el atacante tiene varios hashes para romper (esa es la situación de LinkedIn). Con hashes sin sal, el atacante puede hash una contraseña potencial y buscar el resultado en la lista completa de hashes que quiere descifrar.

• Paralelismo en el tiempo es cuando el atacante calcula los hashes de las contraseñas comunes, en una tabla grande (con o sin arco iris), para aplicar en los hashes que posteriormente obtiene.

Lo que Ptacek quiso decir fue que:

• Las sales solo hacen la mitad del trabajo; Para realmente ralentizar al atacante, necesitas un proceso de hashing inherentemente lento, como bcrypt .

• Cuando hay muchos usuarios, al menos algunas de las contraseñas serán tan débiles que se las descifrará, independientemente de la cantidad de cifrado que saques.

Entonces, si bien las sales hubieran mejorado la situación para LinkedIn, no las habrían salvado , sino que se habrían retrasado y diluido un poco el problema. El uso de bcrypt o PBKDF2 habría mejorado aún más las cosas, pero no hasta el punto de que la violación podría ser totalmente ignorada.

Si un atacante explota un sistema, y la sal también se ve comprometida, la diferencia es que las tablas de arco iris precalculadas serán inútiles. (Cualquier contraseña en particular podría almacenarse de diferentes maneras, dependiendo del tamaño de sal). Como las tablas Rainbow son una compensación entre el tiempo y el espacio, se necesitaría mucho más espacio.

Espero que ayude. Un ejemplo es el uso de sal en el archivo shadow en UNIX, descrito claramente aquí: ¿Por qué shadow?

En realidad, Ptacek no dice que una sal no hubiera impedido que se descifren las contraseñas de LinkedIn. Tendría que argumentar que, dependiendo del tamaño de la sal, incluso habría protegido la peor de las contraseñas.

La única debilidad SHA1 es su debilidad a un ataque de fuerza bruta. Todo lo que tienes que hacer es generar X hashes con anticipación y comparar el valor del hash SHA1 de una cadena con la lista de hashes generada.

Con un salt que depende del tamaño para generar la lista antes de tiempo, tomaría mucho tiempo y una gran cantidad de almacenamiento en disco. Debe recordar que uno tendría que generar la misma lista para cada sal posible. En este punto, su única esperanza es probar cada combinación y esperar que encuentre una coincidencia. Si puede generar una sal única por usuario sin almacenar la sal en una base de datos, estará aún más seguro.

En otras palabras ... En lugar de descifrar todas las contraseñas ... LinkedIn solo buscaría un porcentaje muy pequeño de las contraseñas de sus usuarios que se filtraron (lo peor de lo peor).

Actualizar

  

¿Dónde guardaría la clave?

Si se hace de la manera correcta, no es necesario almacenarlo. Solo genere una sal basada en el nombre de usuario, cuando se creó la cuenta, o una combinación de las dos y usted tendría una sal única para el usuario dado.

Entonces, a menos que se filtrara la fuente de su sitio web, los hackers no podrían generarla. Incluso podría hacer esto más seguro y generar un nuevo salt cuando el usuario cambiara la contraseña de la cuenta.

Una persona con las tablas de base de datos robadas tiene solo 2 campos por usuario.

password hash                                  salt
c32528b3e9191a8c7471252c6de289939a1e6f01       cGFzc3dvcmQ

En los términos más básicos, de la forma en que lo entiendo, todo lo que hace la salada es hacer que la contraseña sea más larga .

La contraseña original era "contraseña". Pero adjunté a la contraseña antes de calcular el hash del salt cGFzc3dvcmQ para hacer passwordcGFzc3dvcmQ . ¿Qué hace eso? Bueno, solo lo hace así si tienes una tabla de contraseñas comunes y sus hashes,

password                        hash
password                        5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

donde puede ver de un vistazo que SHA('password')=5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 , buscar la contraseña original del hash es muy simple. Queremos que el cracker tenga que trabajar un poco para ello.

Así que vamos "¡Dyoh! Ya sea que hayamos agregado o añadido ANTES DE ESTA CADENA ALEATORIA A LA contraseña original. Ahora tus tablas hash de contraseñas comunes y sus hashes son inútiles"

Que son ellos. Debido a que complejizamos cada contraseña por la cadena aleatoria, básicamente "mejoramos las contraseñas del usuario" y arruinamos por completo los hashes para que ahora sean completamente infrecuentes.

Así que la salada lo hace así que cada hash debe ser resquebrajado individualmente , porque para hacerlo, si el cracker tiene las sales, el cracker tiene que agregar / añadir la sal a cada uno común. contraseña lo intenta. 2 usuarios diferentes podrían usar la contraseña simple password , pero el craqueo será 2 trabajos completamente separados para el cracker, debido a la sal. Por lo tanto, descifrar todas las contraseñas tomará más tiempo.

El artículo aquí dice que debido al poder de cómputo disponible hoy, sin embargo, usando Las sales son triviales para agrietarse.