¿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 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 ¹⁵ * 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 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 ¹⁶⁰ operaciones, lo que significa que nuestro atacante teórico necesitaría 10 ³⁰ años para llevarlo a cabo. Los límites de posibilidad teórica son alrededor de 2 ⁶⁰ 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 ¹⁶⁰ operaciones a 2 ¹⁵⁷) 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 ⁸⁰ a 2 ⁵² ), 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 ¹⁰⁶ 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?

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 ¹⁰⁶ segundos 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; 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 ⁿ 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 ² ) 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 ...

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:

• /crypto/400/why-cant-one-implement-bcrypt-in-cuda
• http://codahale.com/how-to-safely-store-a-password/
• http://www.codinghorror.com/blog/2012/04/speed-hashing.html
• /security/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

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í .

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:

• https://en.wikipedia.org/wiki/Argon2
• https://en.wikipedia.org/wiki/Bcrypt
• https://en.wikipedia.org/wiki/Scrypt
• https://en.wikipedia.org/wiki/PBKDF2

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.

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í.

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.