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


148

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 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 exactamente eso. Supongamos que tengo una base de datos de hash de contraseñas SHA-1, y un atacante con un algoritmo de última generación SHA-1 y una botnet con 100,000 máquinas tiene acceso a ella. (Tener control sobre 100k computadoras en el hogar significaría que pueden hacer aproximadamente 10 ^ 15 operaciones por segundo). ¿Cuánto tiempo necesitarían para

  1. averiguar la contraseña de cualquier usuario?
  2. averiguar la contraseña de un usuario determinado?
  3. averiguar la contraseña de todos los usuarios?
  4. ¿encuentra una manera 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 se salan las contraseñas? ¿Importa el método de salazón (prefijo, postfix, ambos o algo más complicado como xor-ing)?

Aquí está mi comprensión actual, después de buscar en Google. Corrija las respuestas si no he entendido algo.

  • Si no hay sal, un ataque de arco iris encontrará inmediatamente todas las contraseñas (excepto las extremadamente largas).
  • Si hay una sal aleatoria suficientemente larga, la forma más efectiva de encontrar las contraseñas es una fuerza bruta o un ataque de diccionario. Ni los ataques de colisión ni los de preimagen son de ninguna ayuda para descubrir 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 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 10 15 * 60 * 60 * 24/1000 ~ = 10 17 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 tarda 60 veces más por 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 dé como resultado 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 2 160 operaciones, lo que significa que nuestro atacante teórico necesitaría 10 30 años para llevarlo a cabo. Los límites de posibilidad teórica son alrededor de 2 60 operaciones, en las cuales el ataque tomaría algunos años). Hay ataques previos a la imagen. 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 ha disminuido de 2 160 operaciones a 2 157) Hay ataques de colisión contra SHA-1 que están dentro de las posibilidades teóricas ( lo mejor que encontré reduce el tiempo de 2 80 a 2 52 ), pero son inútiles contra 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 de preimagen en 2 106 operaciones . ( Editar: como explica Thomas , este ataque es una construcción hipotética que no se aplica a escenarios de la vida real). Sin embargo, todavía no veo cómo esto significa peligro para el uso de SHA-1 como una función de derivación clave. ¿Existen generalmente buenas razones para pensar que un ataque de colisión o un segundo ataque de preimagen pueden convertirse en un primer ataque de preimagen?


Ahora tiene 7 años y han pasado muchas cosas desde la última edición. SHA-1 ya no se considera suficientemente segura para hash contraseña
GordonM

@GordonM, ¿qué pasó? Con el crecimiento de la potencia informática, los ataques de colisión SHA-1 son cada vez más prácticos, pero no son realmente relevantes aquí. SHA-1 nunca fue realmente seguro para el hashing de contraseñas (los hashes rápidos generalmente no lo son), pero en la medida en que lo fue, todavía es AFAIK.
Tgr

SHA-1 nunca fue seguro para el hashing de contraseñas porque nunca tuvo la intención de proteger las contraseñas en primer lugar ...
Azxdreuwa

Respuestas:


209

La respuesta corta a su 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 las 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 de la ronda 2 de SHA-3 parecen ser más rápidos que SHA-1, aunque posiblemente sean "más seguros"; Sin embargo, todavía son un poco nuevos, por lo que apegarse a SHA-256 o SHA-512 sería una ruta más segura en este momento. Te haría ver profesional y cauteloso, lo cual es bueno.

Tenga en cuenta que "lo más seguro posible" no es lo mismo que "perfectamente seguro". Vea a continuación explicaciones bastante largas.

Sobre ataques conocidos:

Los ataques conocidos en MD4, MD5 y SHA-1 son sobre colisiones, que no afectan la resistencia previa a la imagen. Se ha demostrado que MD4 tiene algunas debilidades que pueden ser (solo teóricamente) explotadas cuando se trata de romper HMAC / MD4, pero esto no se aplica a su problema. El ataque de preimagen de 2 106 segundos en el documento de Kesley y Schneier es una compensación genérica que se aplica solo a entradas muy largas (2 60 bytes; eso es un millón de terabytes; observe cómo 106 + 60 excede 160; ahí es donde ve que la compensación no tiene nada de magia).

El resto de este mensaje supone que la función hash que usa (por ejemplo, SHA-1) es un "cuadro negro" 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.

Sobre las mesas arcoiris:

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

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

  1. El ataque de fuerza bruta / diccionario ha costado N por descifrar cada contraseña.
  2. Con una tabla precalculada, el atacante paga lo que cuesta N una vez y luego puede atacar muchas contraseñas con un costo adicional muy pequeño por contraseña.
  3. Si la tabla calculada previamente es una tabla arcoíris, entonces N puede ser algo mayor, 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 en el tamaño de sus discos duros.

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

Sobre sales:

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

Desea la salazón porque cuando los datos hash consisten en contraseñas , es decir, algo que cabe dentro del cerebro de un ser humano aleatorio, entonces N puede ser bastante bajo: los humanos son muy malos para elegir y recordar contraseñas. De esto se tratan los "ataques de diccionario": usar un espacio reducido de contraseñas potenciales (el "diccionario") bajo el supuesto de que muchas contraseñas de usuarios estarán en ese espacio especialmente seleccionado.

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

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

Sobre el costo SHA-1:

El costo elemental de SHA-1 se trata de trocear 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, así que multiplíquelos en consecuencia.

Algunos esquemas de salazón prescriben sales enormes; por ejemplo, lo que ingresa a la función hash es en realidad 40000 copias sucesivas de una única sal de 128 bits, seguida de la contraseña misma. 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 esta 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 le tomó 10 ms descifrar su contraseña, en lugar de 1 µs; pero el costo para el atacante ha aumentado en un factor muy notable de 10000. En servidores compartidos con miles de clientes por segundo, el costo agregado puede volverse prohibitivo. Conceptualmente, elevar el listón 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.

Sobre los ataques en línea:

Todo lo anterior se trata de derrotar ataques fuera de línea . Un ataque fuera de línea es un ataque en el que el atacante tiene todos los datos que necesita para "probar" las contraseñas; por ejemplo, el atacante podría obtener una copia de la base de datos que contiene las contraseñas hash. 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 intento 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 al imponer límites sobre cuántas contraseñas se pueden probar por segundo. Ejemplos extremos son las tarjetas inteligentes que se apagan después de tres PIN incorrectos.

Por lo general, para la seguridad de la contraseña, vale mucho más organizar el sistema para no permitir que un atacante cree un ataque fuera de línea. Eso es lo que hacen los sistemas Unix: las contraseñas hash, que solían estar en el /etc/passwordarchivo legible en todo el mundo , ahora están en el /etc/shadowarchivo que está protegido contra el acceso de lectura, excepto por algunas aplicaciones privilegiadas. La suposición aquí es que si el atacante puede leer /etc/shadow, entonces probablemente tenga suficiente control sobre el sistema que realmente ya no necesita contraseñas ...


55
Excelente respuesta Lo único con lo que no estoy de acuerdo es "Conceptualmente, elevar el listón por el mismo factor para el usuario legítimo y el atacante no es, en última instancia, una buena seguridad": el atacante tiene que hacer un gran múltiplo de las operaciones que debe realizar un usuario. Agregar un ciclo de reloj para un inicio de sesión de usuario agrega millones para un atacante.
Nick Johnson,

1
@Thomas Esto sigue siendo exacto y probablemente lo seguirá siendo en el futuro previsible indefinido. Los hackers pueden adivinar las contraseñas reales a través de cualquier tipo de hash debido a la mala calidad de las contraseñas comunes. Adivina "123456" y siempre obtendrás algunos golpes. Esto seguirá siendo cierto sin importar el almacenamiento de contraseña que use.
tylerl

1
Solo es mi punto de vista, pero ¿por qué te quedarías con SHA1, cuando el cifrado de contraseña más fuerte ya está ampliamente disponible? Hace un año, MD5 se consideraba "seguro", y ahora no lo es; lo mismo podría pasar con SHA1 en cualquier momento, por lo que sabemos. Personalmente, apostaré por Blowfish de ahora en adelante: parece tener un mejor representante y menos expertos preocupados en la comunidad de cifrado, está disponible en casi cualquier lugar, por lo que no hay razón para apostar con SHA1.
mindplay.dk

1
Estoy impactado hasta el fondo por extraviar una respuesta de @ThomasPornin que dice que MD5 es seguro para el almacenamiento de contraseñas. Si MD5 está bien, ¿por qué TODO dice que no lo use, use bcrypt? ¿Están siendo demasiado cautelosos? He leído y entendido todo y tenía la impresión de que MD5 era muy malo porque era muy vulnerable a la fuerza bruta. Los comentarios de hace tan solo un año no contradicen la respuesta ...
temporary_user_name

1
@Aerovistae: es posible que desee ver esa respuesta en el sitio security.SE; Contiene más análisis y detalles recientes sobre hashing de contraseñas.
Thomas Pornin

30

Las respuestas anteriores no mencionan las GPU, que pueden paralelizar el hash SHA-1 en la medida en que una base de datos completa ahora puede ser forzada en minutos u horas en lugar de días o semanas, incluso si las contraseñas han sido saladas.

Los algoritmos modernos de hash de contraseña, 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 en bloque con requisitos de memoria mucho más altos (y el acceso a la memoria en una GPU no se puede paralelizar 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 del arte.

Para más lectura:


2
"Los algoritmos modernos de hash de contraseña como bcrypt o PBKDF2 están diseñados específicamente para ser difíciles de ejecutar en GPU" . ¿Quiso decir "bcrypt o scrypt"? PBKDF2 es solo hashing iterado, no hay nada en él que pueda ser problemático para una GPU.
Tgr

44
Por favor, hágame saber qué GPU usa, compraré la misma. Si puede hacer 2 ^ 160 cálculos SHA-1 en "minutos" (eso sería menos de "horas", entonces como máximo 59 minutos), necesita poder realizar más de 10 ^ 44 por segundo. Dado que PCIe transfiere un límite de alrededor de 128GT / s, su GPU también debe tener una increíble memoria integrada. Lo quiero.
Damon

3
@Damon: Parece suponer que los usuarios tienen contraseñas "triviales" (<8 bits de entropía) o contraseñas "irrompibles" (> 60 bits de entropía). Estás ignorando por completo a todos entre cuya contraseña la entropía está en el rango de 10-60 bits. Esos son los usuarios donde bcrypt, tablas de arcoiris y GPU, y representan típicamente alrededor del 80% de una base de usuarios típica.
jammycakes

1
(Uy ... Debería haber dicho, "Esos son los usuarios donde bcrypt, tablas de arco iris y GPU hacen la mayor diferencia")
jammycakes

3
Para algunas estadísticas y análisis, visite troyhunt.com/2011/06/brief-sony-password-analysis.html , mientras que el 36% de los usuarios elige las contraseñas que aparecen en los diccionarios de contraseñas, solo el 2-3% elige las más comunes.
jammycakes

7

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: al menos, debes repetir 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 hashing de contraseñas que ellos).

Sin embargo, idealmente, debe usar una primitiva de almacenamiento de contraseña existente, como las que se describen aquí .


Iterar miles de veces no es una idea tan buena como podría pensar. Aumenta el riesgo de una colisión de hash. yorickpeterse.com/articles/use-bcrypt-fool
jammycakes

1
Ese artículo parece completamente confundido. Una función de hash segura no pierde entropía apreciable a través del hashing iterativo, y el hashing iterativo es un componente central de los esquemas de estiramiento clave como PBKDF2 y scrypt. Incluso bcrypt, que el autor recomienda, usa una construcción similar. Su 'ataque' se basa en encontrar una preimagen de un hash, en cuyo caso, la mayoría de las construcciones que usan ese hash se rompen por completo de todos modos. Finalmente, no recomiendo que las personas usen hashing iterativo directamente; como digo en mi pregunta, debe usar una primitiva existente diseñada para ese propósito.
Nick Johnson

7

SHA1 es un resumen de mensaje , nunca fue 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 debe defenderse contra ataques de diccionario y tablas de arcoiris. Se han diseñado varios algoritmos para lograr este objetivo.

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

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

Wikipedia tiene páginas para estas funciones:


4

Se han descubierto serias 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 medida intratable, pero no se espera que sea así por mucho tiempo; Los programadores paranoicos prefieren algo de la familia SHA-2.

A partir de este artículo en relación con el resultado original 2005:

"Es hora de caminar, pero no correr, hacia 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 la comunidad criptográfica está preocupada de que peores noticias 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 continua de SHA-3 .

En resumen, SHA-1 es seguro en este momento, y probablemente lo será por algún tiempo, pero la comunidad criptográfica se siente incómoda con el pronóstico.


¿Podría proporcionar un enlace? Como dije, el mejor ataque de preimagen que pude encontrar hace que la búsqueda sea 8 veces más rápida, e incluso para que eso funcione, debes omitir la mitad de los pasos de SHA-1. (Además, creo que es un segundo ataque imagen inversa, que es inútil contra los hashes de contraseñas.)
Tgr

También soy escéptico de algo que proviene de la NSA, a la luz de las noticias recientes :)
Alex W

4

A partir de febrero de 2017, SHA-1 ya no debería considerarse seguro. Google ha reportado el é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 señalaron otros, las contraseñas no son vulnerables a los ataques de colisión de hash. Sin embargo, como pauta general, no elegiría SHA-1 para aplicaciones relacionadas con la seguridad. Hay mejores alternativas por ahí.


OK, encontrar una colisión SHA-1 tomó aproximadamente 6,500 años de CPU y 100 años de GPU , no es un ataque de producción. Descifrar contraseñas no es una fuerza bruta contra todas las entradas posibles, sino contra listas de 10,000,000 contraseñas frecuentes. Aquí está el papel .
zaph

1
La falla está usando solo cualquier función hash para proteger las contraseñas. Solo usar una función hash no es suficiente y solo agregar una sal hace poco para mejorar la seguridad, los hash criptográficos son muy rápidos. En su lugar, repita sobre un HMAC con una sal aleatoria durante aproximadamente 100 ms y guarde la sal con el hash. Uso de las funciones tales como PBKDF2(aka Rfc2898DeriveBytes), password_hash/ password_verify, Bcrypty funciones similares. El punto es hacer que el atacante pase mucho tiempo buscando contraseñas por fuerza bruta. Proteger a sus usuarios es importante, utilice métodos de contraseña segura.
zaph

La colisión no es una imagen previa y las contraseñas no son firmas. Los ataques de colisión no funcionan contra las contraseñas porque requieren el conocimiento del texto sin formato original.
Tgr

Tgr: de acuerdo, gracias. Zaph: Sí, la salazón para salvaguardar contra los ataques del arco iris y el uso de hash criptográficos lentos se encuentran entre las prácticas recomendadas que no mencioné específicamente en esta respuesta.
Aaron

3

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 realmente paranoico.

Esto es lo que dice NIST :

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


Ese es un comentario de NIST de 2004. Su proyecto de recomendación de 2010 dice que SHA-1 está aprobado para todas las aplicaciones de generación de firma no digital más allá de 2010.
Tgr
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.