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

Question

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

Conclusión: SHA-1 es tan seguro como cualquier cosa contra ataques preimágenes, sin embargo es fácil de calcular, lo que significa que es más fácil montar un ataque de fuerza bruta o de diccionario. (Lo mismo es cierto para 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 muchos comentarios como "SHA-1 está roto", así que estoy tratando de entender qué es exactamente eso significa. Supongamos que tengo una base de datos de hashes de contraseñas SHA-1, y un atacante con un algoritmo de ruptura SHA-1 de última generación y una botnet con 100.000 máquinas obtiene acceso a ella. (Tener control sobre 100k computadoras domésticas significaría que pueden hacer alrededor de 10^15 operaciones por segundo.) ¿Cuánto tiempo necesitarían

encontrar la contraseña de cualquier usuario?
averiguar la contraseña de un usuario determinado?
encontrar la contraseña de todos los usuarios?
encontrar una manera de iniciar sesión como uno de los usuarios?
encontrar una manera de iniciar sesión como un usuario específico?

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

Aquí está mi comprensión actual, después de buscar en Google. Por favor, corrija las respuestas si malinterpreté algo.

Si no hay sal, un ataque rainbow encontrará inmediatamente todas las contraseñas (excepto extremadamente largas aquel).
Si hay una sal aleatoria suficientemente larga, la forma más efectiva de averiguar las contraseñas es un ataque de fuerza bruta o de diccionario. Ni los ataques de colisión ni los ataques de preimagen son de ayuda para 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 utilice, 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 cuán seguro es "igual de seguro", supongamos que una sola ejecución sha1 toma 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 10¹⁵*60*60*24 / 1000 ~= 10¹⁷ contraseña potencial al día. Para un ataque de fuerza bruta, eso significaría probar todas las contraseñas 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 carácter 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 encontrar una cadena que resulte en el mismo hash. Esto se llama un primer ataque de preimagen. Por lo que pude encontrar, no hay ataques preimágenes contra SHA-1. (Un ataque de fuerza bruta tomaría 2¹⁶⁰ operaciones, lo que significa nuestro atacante teórico necesitaría 10³⁰ años para lograrlo. Los límites de la posibilidad teórica están alrededor 2⁶⁰ operaciones, en las que el ataque tardaría unos 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 se reduce desde 2¹⁶⁰ operaciones para 2¹⁵⁷). Hay ataques de colisión contra SHA-1 que están bien dentro de lo teórico posibilidad ( lo mejor que encontré reduce el tiempo de 2⁸⁰ to 2⁵²), pero esos son inútiles contra los hashes de contraseñas, incluso sin sal.

En resumen, almacenar 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 preimagen en 2¹⁰⁶ operaciones . (Editar: Como Thomas explica , este ataque es un hipotético construcción que no se aplica a escenarios de la vida real.) Todavía no veo cómo esto deletrea peligro para el uso de SHA-1 como una función de derivación clave, aunque. ¿Hay generalmente buenas razones para pensar que un ataque de la colisión o un segundo ataque de la preimagen puede ser convertido eventual en un primer ataque de la preimagen?

141

cryptography hash sha1

Author: Community, 2010-05-05

Source

7 answers

Las respuestas anteriores no hacen ninguna mención de las GPU, que pueden paralelizar el hash SHA-1 hasta el punto de que una base de datos completa ahora puede ser forzada brutalmente en minutos u horas en lugar de días o semanas, incluso si las contraseñas han sido saladas.

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 al hecho de que son cifrados de bloque con requisitos de memoria mucho más altos (y el acceso a la memoria en una GPU no puede ser paralelo 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 la tecnología mejora.

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

Para más lectura:

28

Author: jammycakes,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-04-13 12:48:18

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

Sin embargo, no deberías usar una sola iteración de ninguna función hash: Como mínimo, deberías 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ñas que ellos).

Idealmente, sin embargo, debe usar una primitiva de almacenamiento de contraseñas existente, como las descritas aquí.

7

Author: Nick Johnson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-05-05 15:11:51

SHA1 es un message digest, fue nunca destinado a ser una función de hash 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ña 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ña ganó el Password Hashing Competition en 2015.

Si Argon2 no está disponible, la única otra función estandarizada de hash de contraseña o derivación de claves es PBKDF2, que es un estándar NIST antiguo. Otras opciones, si no se requiere el uso de un estándar, incluyen bcrypty el scrypt.

Wikipedia tiene páginas para estos funciones:

6

Author: Erwan Legrand,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-03-07 10:42:24

Se han descubierto vulnerabilidades graves 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 por 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 ves humo, pero las alarmas de incendio se han apagado."

No es que el criptoanálisis actual hace que SHA-1 sea inseguro, sino que la comunidad criptográfica está preocupada de que las noticias peores puedan estar a la vuelta de la esquina. Este miedo 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 es seguro en este momento, y probablemente lo será durante algún tiempo, pero la comunidad criptográfica se siente incómoda con el pronóstico.

4

Author: Marcelo Cantos,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-05-05 10:05:52

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

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

4

Author: Aaron,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-02-24 05:51:05

Si almacena la contraseña salada, 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 dice el NIST :

Los resultados presentados hasta ahora en SHA-1 no llame a su seguridad en pregunta. Sin embargo, debido a los avances en tecnología, NIST planea eliminar gradualmente SHA-1 a favor de la más grande y funciones hash más potentes (SHA-224, SHA-256, SHA-384 y SHA-512) por 2010.

3

Author: VladV,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-05-05 10:07:15

score 203 · Accepted Answer

La respuesta corta a tu pregunta es: SHA-1 es lo más seguro posible. 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 costos de almacenamiento). Algunos de los candidatos SHA-3 round-2 parecen ser más rápidos que SHA-1 mientras que son posiblemente "más seguros"; sin embargo, todavía son un poco nuevos, por lo que se adhieren a SHA-256 o SHA - 512 sería una ruta más segura ahora mismo. Te haría parecer profesional y cauteloso, lo cual es bueno.

Tenga en cuenta que "tan seguro como pueda obtener" no es lo mismo que "perfectamente seguro". Vea más abajo para explicaciones bastante largas.

Acerca de los ataques conocidos:

Los ataques conocidos en MD4, MD5 y SHA-1 son sobre colisiones, que no afectan la resistencia preimagen. Se ha demostrado que MD4 tiene algunas debilidades que pueden ser (solo teóricamente) explotadas cuando se intenta para romper HMAC / MD4, pero esto no se aplica a su problema. Las 2¹⁰⁶ el segundo ataque de preimagen en el documento de Kesley y Schneier es una compensación genérica que se aplica solo a entradas muy largas (2⁶⁰ bytes; eso es un millón de terabytes notice observe cómo 106+60 supera los 160; ahí es donde ve que el trade-off 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 puede usar. Eso es lo que tienes ahora mismo incluso con las funciones hash" rotas " MD5 y SHA-1.

Acerca de las tablas rainbow:

El "ataque arco iris" es en realidad el costo compartido de un diccionario o ataque de fuerza bruta. Es un derivado de la time-memory trade-off descrita por primera vez por Hellman en 1980. Asumiendo que tienes N posibles contraseñas (ese es el tamaño de tu diccionario, o 2ⁿ si consideras forzar brutalmente un hash función con una salida de n bits), hay un ataque de tiempo compartido en el que precomputa las contraseñas hash N y las almacena en una tabla grande. Si ordena las salidas hash, puede obtener su contraseña en una sola búsqueda. Una mesa rainbow es una forma inteligente de almacenar esa mesa con un espacio muy reducido. Solo almacena N/t contraseñas con hash, y las rompe con O (t²) búsquedas. Las mesas Rainbow le permiten manejar virtualmente precomputados mesas mucho más grandes de lo que puede almacenar de manera realista.

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

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

Si N es lo suficientemente grande como para que el costo de CPU de 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 un (resistente a la imagen previa) la función hash con una salida de 80 bits o más es suficiente para hacer que el ataque de fuerza bruta sea inviable.

Acerca de las sales:

Las sales son una forma de derrotar los pre-cálculos. En la descripción anterior, salt devuelve al atacante al paso 1: salting evita que el atacante comparta el costo de O(N) entre varias contraseñas atacadas. Las tablas pre-calculadas, a fortiori rainbow tables, ya no son factibles.

Quieres salar porque cuando los datos hash consisten en contraseñas, es decir, algo que encaja dentro del cerebro de un ser humano al azar, entonces N puede ser bastante bajo: los humanos son realmente malos para elegir y recordar contraseñas. Esto es de lo que se tratan los "ataques de diccionario": eso es usar un espacio reducido de contraseñas potenciales (el "diccionario") bajo la suposición de que muchas contraseñas de usuario estarán en ese espacio especialmente seleccionado.

Por lo tanto, la salazón al menos evitará que el atacante utilizando tablas pre-calculadas, en particular tablas arcoíris pre-calculadas. Esto supone que el atacante será capaz de romper una o dos contraseñas; no queremos que rompa otras 1000 contraseñas con poca sobrecarga adicional.

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

Acerca de SHA-1 costo:

El costo elemental de SHA-1 consiste en hashear 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 una un solo bloque es alrededor de 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 con aproximadamente 400 y 250 ciclos, respectivamente. No olvide que la mayoría de las CPU modernas tienen varios núcleos, así que multiplique en consecuencia.

Algunos esquemas de salazón prescriben enormes sales; por ejemplo, lo que entra en la función hash es en realidad 40000 copias sucesivas de una sola sal de 128 bits, seguida de la propia contraseña. Esto hace que el hashing de contraseñas sea más caro (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ó 10ms para hash 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 llegar a ser prohibitivo. Conceptualmente, elevar el nivel 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 valga la pena en algunas situaciones específicas.

Acerca de los ataques en línea:

Todo lo anterior se trata de derrotar ataques fuera de línea. Un ataque sin conexión es un ataque en el que el atacante tiene todos los datos que necesita para "probar" contraseñas; por ejemplo, el atacante podría obtener una copia de la base de datos que contiene las contraseñas cifradas. En un ataque fuera de línea, el atacante está limitado solo por sus recursos computacionales. Por el contrario, un ataque en línea es un ataque en el que cada conjetura 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 frustran imponiendo límites a la cantidad de contraseñas que se pueden probar por segundo. Ejemplos extremos son las tarjetas inteligentes que se apagan después de tres PINES incorrectos.

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