it-swarm-es.com

¿Es seguro SHA-1 para el almacenamiento de contraseñas?

Conclusión: SHA-1 es tan seguro como cualquier cosa contra los ataques de preimagen, sin embargo, es fácil de calcular, lo que significa que es más fácil montar un ataque de fuerza bruta o diccionario. (Lo mismo es cierto para los sucesores como SHA-256). Dependiendo de las circunstancias, una función hash que fue diseñada para ser computacionalmente costosa (como bcrypt) podría ser una mejor opción.


Algunas personas lanzan comentarios como "SHA-1 está roto" mucho, así que estoy tratando de entender qué significa eso exactamente. Supongamos que tengo una base de datos de hashes SHA-1, y un atacante con un algoritmo de ruptura SHA-1 de última generación y una botnet con 100,000 máquinas tienen acceso a él. (Tener control sobre computadoras domésticas de 100k significaría que pueden hacer aproximadamente 10 ^ 15 operaciones por segundo). ¿Cuánto tiempo necesitarían para

  1. ¿Descubrir la contraseña de cualquier usuario?
  2. ¿Descubrir la contraseña de un usuario determinado?
  3. ¿Averiguar la contraseña de todos los usuarios?
  4. ¿Encontrar la forma de iniciar sesión como uno de los usuarios?
  5. ¿Encuentra una manera de iniciar sesión como usuario específico?

¿Cómo cambia eso si las contraseñas son saladas? ¿Importa el método de salado (prefijo, postfijo, ambos, o algo más complicado como xoring)?

Aquí está mi comprensión actual, después de algunos googlear. Por favor corrija en las respuestas si entendí mal algo.

  • Si no hay sal, un ataque Rainbow detectará inmediatamente todas las contraseñas (excepto las extremadamente largas).
  • Si hay una sal aleatoria suficientemente larga, la forma más efectiva de descubrir las contraseñas es un ataque de fuerza bruta o diccionario. Ni la colisión ni los ataques previos a la imagen ayudan a encontrar la contraseña real, por lo que los ataques criptográficos contra SHA-1 no son de ayuda aquí. Ni siquiera importa mucho qué algoritmo se use, incluso se podría usar MD5 o MD4 y las contraseñas serían igual de seguras (hay una ligera diferencia porque calcular un hash SHA-1 es más lento).
  • Para evaluar qué tan seguro es "igual de seguro", supongamos que una sola ejecución de sha1 requiere 1000 operaciones y las contraseñas contienen mayúsculas, minúsculas y dígitos (es decir, 60 caracteres). Eso significa que el atacante puede probar 1015* 60 * 60 * 24/1000 ~ = 1017 contraseña potencial al día. Para un ataque de fuerza bruta, eso significaría probar todas las contraseñas de hasta 9 caracteres en 3 horas, hasta 10 caracteres en una semana, hasta 11 caracteres en un año. (Se necesita 60 veces más para cada personaje adicional). Un ataque de diccionario es mucho, mucho más rápido (incluso un atacante con una sola computadora podría llevarlo a cabo en horas), pero solo encuentra contraseñas débiles.
  • Para iniciar sesión como usuario, el atacante no necesita encontrar la contraseña exacta; es suficiente para encontrar una cadena que resulta en el mismo hash. Esto se llama un primer ataque de preimagen. Por lo que pude encontrar, no hay ataques de preimagen contra SHA-1. (Un ataque de fuerza bruta tomaría 2160 Operaciones, lo que significa que nuestro atacante teórico necesitaría 1030 Años para lograrlo. Los límites de posibilidad teórica son alrededor de 2.60 operaciones, en las que el ataque llevaría unos pocos años.) Hay ataques de preimagen contra versiones reducidas de SHA-1 con efecto insignificante (para el SHA-1 reducido que usa 44 pasos en lugar de 80, el tiempo de ataque es bajo a partir del 2160 operaciones a 2157). Hay ataques de colisión contra SHA-1 que están dentro de las posibilidades teóricas ( el mejor que encontré reduce el tiempo de 280 a 252), pero esos son inútiles contra hashes de contraseña, incluso sin sal.

En resumen, el almacenamiento de contraseñas con SHA-1 parece perfectamente seguro. ¿Me he perdido algo?

Actualización: Marcelo señaló un artículo que menciona un segundo ataque de preimagen en 2106 operaciones . (Editar: Como Thomas explica , este ataque es un constructo hipotético que no se aplica a los escenarios de la vida real.) Todavía no veo cómo esto crea peligro para el uso de SHA- 1 como una función de derivación clave, sin embargo. ¿Hay razones generalmente buenas para pensar que un ataque de colisión o un segundo ataque de pre-imagen puede eventualmente convertirse en un primer ataque de pre-imagen?

144
Tgr

La respuesta corta a su pregunta es: SHA-1 es lo más seguro que puede obtener. MD5 también estaría bien, incluso MD4; Pero podría poner nerviosos a algunos inversores. Para relaciones públicas, es mejor usar una función hash "mejor", por ejemplo. SHA-256, incluso si trunca su salida a 160 o 128 bits (para ahorrar en el costo de almacenamiento). Algunos de los candidatos de SHA-3 round-2 parecen ser más rápidos que SHA-1 mientras que se dice que son "más seguros"; sin embargo, aún son un poco nuevos, por lo que seguir un SHA-256 o SHA-512 sería una ruta más segura ahora. Te haría lucir profesional y cauto, lo cual es bueno.

Tenga en cuenta que "tan seguro como pueda obtener" no es lo mismo que "perfectamente seguro". Vea a continuación las explicaciones bastante largas.

Sobre ataques conocidos:

Los ataques conocidos en MD4, MD5 y SHA-1 son sobre colisiones, que no afectan la resistencia de preimagen. Se ha demostrado que MD4 tiene algunos puntos débiles que pueden ser explotados (solo en teoría) cuando se intenta romper HMAC/MD4, pero esto no se aplica a su problema. El 2106 El segundo ataque de preimagen en el documento de Kesley y Schneier es un compromiso genérico que se aplica solo a insumos muy largos (260 bytes eso es un millón de terabytes: observe cómo 106 + 60 superan los 160; ahí es donde se ve que la compensación no tiene nada de mágico).

El resto de este mensaje asume que la función hash que usa (por ejemplo, SHA-1) es una "caja negra" sin ninguna propiedad especial que el atacante pueda usar. Eso es lo que tiene ahora, incluso con las funciones hash "rotas" MD5 y SHA-1.

Acerca de las tablas de Rainbow:

El "ataque del arco iris" es en realidad el costo compartido de un diccionario o ataque de fuerza bruta. Es un derivado del compromiso de memoria de tiempo descrito por primera vez por Hellman en 1980. Suponiendo que tiene N posibles contraseñas (ese es el tamaño de su diccionario, o 2n si considera que una función hash forzada de forma bruta con una salida de n bits), hay un ataque de tiempo compartido en el que usted calcula previamente las contraseñas hash N y las almacena en una mesa grande Si ordena las salidas de hash, puede obtener su contraseña en una sola búsqueda. Una tabla del arco iris es una forma inteligente de almacenar esa tabla con un espacio muy reducido. Almacena solo N/t contraseñas con hash, y descifra contraseñas con O (t2) búsquedas. Las tablas Rainbow le permiten manejar virtualmente tablas precomputadas mucho más grandes de lo que realmente puede almacenar.

Sin embargo, Rainbow o no, el atacante todavía tiene que ejecutar el ataque completo al menos una vez. Esto puede verse como varias capas de optimización sucesivas:

  1. El ataque de fuerza bruta/diccionario ha costado N para descifrar cada contraseña.
  2. Con una tabla precalculada, el atacante paga ese costo N una vez y luego puede atacar muchas contraseñas con un costo extra muy pequeño por contraseña.
  3. Si la tabla precalculada es una tabla Rainbow, entonces N puede ser algo más grande, porque almacenamiento el costo se reduce. El cuello de botella en N se convierte en la potencia de la CPU que el atacante puede reunir, no en el tamaño de sus discos duros.

Si N es lo suficientemente grande como para que el costo de la CPU para el hashing N contraseñas sea ridículo, entonces tal ataque no es factible, independientemente de si se usan tablas Rainbow o no . Esto significa que una función hash (resistente a preimagen) con una salida de 80 bits o más es suficiente para hacer inviable el ataque de fuerza bruta.

Sobre las sales:

Las sales son una forma de vencer los pre-cálculos. En la descripción anterior, la sal devuelve al atacante al paso 1: la aplicación de sal evita que el atacante comparta el costo de O (N) entre varias contraseñas atacadas. Las tablas precalculadas, a fortiori Las tablas del arco iris, ya no son factibles.

Deseas salado porque cuando los datos con hash consisten en contraseñas, es decir, algo que encaja dentro del cerebro de un ser humano aleatorio, entonces N puede ser bastante bajo: los humanos son realmente malos a la hora de elegir y recordar contraseñas. De eso se tratan los "ataques de diccionario": es usar un espacio reducido de contraseñas potenciales (el "diccionario") bajo el supuesto de que habrá muchas contraseñas de usuarios en ese espacio especialmente seleccionado.

Por lo tanto, la salada al menos evitará que el atacante use tablas precalculadas, en particular tablas Rainbow precalculadas. Esto supone que el atacante será capaz de romper una contraseña o dos; No queremos que rompa otras 1000 contraseñas con una pequeña sobrecarga adicional.

Además, la salazón es buena para las relaciones públicas.

Sobre el costo de SHA-1:

El costo elemental de SHA-1 es sobre el hashing de un bloque de 64 bytes. Así es como funciona SHA-1: los datos se rellenan y luego se dividen en bloques de 64 bytes. El costo de procesar un solo bloque es de aproximadamente 500 ciclos de reloj en un sistema Intel Core2, y eso es para un solo núcleo. MD5 y MD4 son más rápidos, cuentan aproximadamente 400 y 250 ciclos, respectivamente. No olvide que la CPU más moderna tiene varios núcleos, por lo tanto, multiplíquelos en consecuencia.

Algunos esquemas de salazón prescriben sales enormes; p.ej. lo que ingresa a la función hash es en realidad 40000 copias sucesivas de un solo sal de 128 bits, seguido de la propia contraseña. Esto hace que el hashing de contraseñas sea más costoso (por un factor de 10000 con mi ejemplo), tanto para el usuario legítimo como para el atacante. Si esto es una buena idea depende de la configuración. Para iniciar sesión en un sistema de escritorio, esto es bueno: el usuario ni siquiera notará que tomó 10 ms para cifrar su contraseña, en lugar de 1µs; pero el costo para el atacante ha aumentado en un factor muy notable 10000. En servidores compartidos con miles de clientes por segundo, el costo agregado puede volverse prohibitivo. Conceptualmente, elevar la barra por el mismo factor para el usuario legítimo y el atacante no es, en última instancia, una buena seguridad; pero puede ser una idea que vale la pena en algunas situaciones específicas.

Sobre ataques en línea:

Todo lo anterior se trata de derrotar a desconectado ataques. Un ataque fuera de línea es un ataque donde el atacante tiene todos los datos que necesita para "probar" las contraseñas; p.ej. el atacante podría obtener una copia de la base de datos que contiene las contraseñas de hash. En un ataque fuera de línea, el atacante está limitado solo por sus recursos computacionales. A la inversa, un en línea ataque es un ataque donde cada intento por parte del atacante debe pasar por un verificador honesto (por ejemplo, el atacante simplemente intenta iniciar sesión en el sistema atacado). Los ataques en línea se ven frustrados al imponer límites a la cantidad de contraseñas que se pueden probar por segundo. Los ejemplos extremos son las tarjetas inteligentes que se apagan después de tres PIN incorrectos.

Por lo general, para la seguridad de las contraseñas, vale mucho más organizar el sistema para no permitir que un atacante cree un ataque sin conexión. Eso es lo que hacen los sistemas Unix: las contraseñas con hash, que solían estar en el archivo /etc/password legible para el mundo, ahora están en el archivo /etc/shadow que está protegido contra el acceso de lectura, excepto por unas pocas aplicaciones privilegiadas. El supuesto aquí es que si el atacante puede leer /etc/shadow, entonces probablemente tenga suficiente control sobre el sistema que ya no necesita contraseñas ...

206
Thomas Pornin

Las respuestas anteriores no hacen mención alguna de las GPU, que pueden ser paralelas al hash SHA-1 en la medida en que una base de datos completa puede ahora ser forzada de forma brutal en minutos u horas en lugar de días o semanas, incluso si las contraseñas han sido incluidas.

Los algoritmos hash de contraseña modernos, como bcrypt o scrypt, están diseñados específicamente para ser difíciles de ejecutar en GPU debido a que son cifrados de bloque con requisitos de memoria mucho mayores (y el acceso a la memoria en una GPU no se puede paralizar en la misma medida). También tienen una "función de trabajo" que les permite ser más lentos sobre la marcha a medida que mejora la tecnología.

En resumen, solo debes usar las mejores herramientas para el trabajo. Y SHA-1 está muy lejos del estado de la técnica.

Para leer más:

30
jammycakes

Su descripción suena precisa para el estado actual de la técnica.

Sin embargo, no deberías usar una única iteración de cualquier función hash: como mínimo, debes iterar muchas veces (1000 iteraciones del hash aumentan el trabajo del atacante 1000 veces. Aumenta tu trabajo en la misma cantidad, pero estás haciendo mucho menos hash de contraseña de lo que son).

Sin embargo, lo ideal es utilizar una primitiva de almacenamiento de contraseña existente, como las que se describen aquí .

7
Nick Johnson

SHA1 es un resumen de mensaje, fue nunca destinado a ser una función de hashing de contraseña (o derivación de clave). (Aunque podría usarse un bloque de construcción para un KDF, como en PBKDF2 con HMAC-SHA1).

Una función de hash de contraseñas debería defenderse contra ataques de diccionario y tablas Rainbow. Se han diseñado varios algoritmos para lograr este objetivo.

Actualmente, la mejor opción es probablemente Argon2. Esta familia de funciones de hash de contraseñas ganó el concurso de hash de contraseñas en 2015.

Si Argon2 no está disponible, la otra función de hashing de contraseña o de obtención de clave estandarizada es PBKDF2, que es un estándar NIST antiguo. Otras opciones, si no se requiere el uso de un estándar, incluyen bcrypt y la scrypt.

Wikipedia tiene páginas para estas funciones:

6
Erwan Legrand

Se han descubierto graves vulnerabilidades en SHA-1 que hacen que la búsqueda sea mucho más rápida que la fuerza bruta. Todavía es en gran parte intratable, pero no se espera que sea el caso durante mucho más tiempo; Los programadores paranoicos favorecen algo de la familia SHA-2.

De este artículo con respecto al resultado original de 2005:

"Es hora de caminar, pero no correr, a las salidas de incendios. No se ve humo, pero las alarmas de incendio se han disparado".

No es que el criptoanálisis actual haga que SHA-1 sea inseguro, sino que a la comunidad de cripto le preocupa que las peores noticias puedan estar a la vuelta de la esquina. Este temor también se aplica a SHA-2, que exhibe los mismos defectos que SHA-1, aunque en un espacio de búsqueda mucho más grande, de ahí la búsqueda en curso de SHA-3 .

En resumen, SHA-1 está a salvo en este momento, y probablemente lo estará por algún tiempo, pero la comunidad criptográfica no se siente cómoda con el pronóstico.

4
Marcelo Cantos

A partir de febrero de 2017, SHA-1 ya no debe considerarse seguro. Google ha informado de éxito con los ataques de colisión contra el SHA-1 completo, no reducido ( enlace al informe ). Para el anuncio de Google, haga clic aquí .

Edición: como han señalado otros, las contraseñas no son vulnerables a los ataques de colisión de hash. Sin embargo, como norma general, no elegiría SHA-1 para aplicaciones relacionadas con la seguridad. Hay mejores alternativas por ahí.

4
Aaron

Si almacena la contraseña con sal, SHA-1 está bien para fines prácticos. SHA-2 se considera más seguro, pero SHA-1 no es un problema a menos que tenga una razón para ser verdaderamente paranoico.

Esto es lo que NIST dice :

Los resultados presentados hasta ahora en SHA-1 no cuestionan su seguridad. Sin embargo, debido a los avances en la tecnología, el NIST planea eliminar el SHA-1 en favor de las funciones hash más grandes y más fuertes (SHA-224, SHA-256, SHA-384 y SHA-512) para 2010.

3
VladV