¿Está AES cifrando una contraseña consigo misma más segura que SHA1?

Respuesta corta: mala idea, no lo hagas.

Respuesta más larga: el objetivo del ejercicio es almacenar algo que le permita al servidor verificar una contraseña determinada, pero no le permite reconstruir la contraseña; esta última propiedad es deseable, por lo que las consecuencias de un acceso ilegítimo de lectura a la base de datos del servidor por parte de un atacante siguen siendo limitadas.

Así que queremos una transformada determinística de una vía que convierte una contraseña dada en el valor de verificación. La transformación será:

• configurablemente lento, para impedir ataques de diccionario;
• distinto para cada instancia, para evitar ataques de diccionario paralelos, incluidas tablas precomputadas (de eso se tratan las sales).

Una sola invocación de MD5 o SHA-1 falla en ambas cuentas, ya que estas funciones son muy rápidas y no tienen sal. La lentitud se puede hacer anidando muchas invocaciones (miles, posiblemente millones), y la sal se puede inyectar "en algún lugar", aunque hay formas buenas y malas de hacerlo. PBKDF2 es una transformación estándar que hace exactamente eso, y no es mala en ello (aunque bcrypt debería ser algo preferible ).

Sin embargo, MD5 y SHA-1 hacen al menos una cosa bien: fueron diseñados para ser de una sola vía. Eso es difícil de hacer; ni siquiera está comprobado teóricamente que las funciones unidireccionales realmente puedan existir. Los criptógrafos de todo el mundo participan actualmente en una competencia para diseñar un nuevo y mejor función hash unidireccional.

Entonces, lo que su profesor parece recomendar es reemplazar una función diseñada para unidireccional, con una función que no fue ni diseñada para unidireccional. No corrige nada acerca de la lentitud y la salazón, pero elimina lo bueno de MD5 y SHA-1. Además, se sabe que AES es relativamente débil con respecto a los ataques de teclas relacionadas, eso no es un problema siempre que como AES se usa para lo que fue destinado, es decir, el cifrado, pero se convierte en un problema importante cuando se subvierte en un bloque de construcción para una función hash de una sola vía. Parece posible crear una función hash segura reutilizando partes del diseño de AES, pero requiere una revisión sustancial (ver, por ejemplo, Whirlpool y ECHO ).

Por lo tanto, no utilice un esquema de hashing de contraseña basado en AES hecho en casa; para eso, no uses nada que sea "casero": esa es una receta para el desastre. La seguridad no puede ser probada; La única forma conocida de hacer un algoritmo seguro es que cientos de criptógrafos entrenados lo vean de cerca durante algunos años. No puedes hacer eso por ti mismo. Incluso un criptógrafo solitario no se arriesgará.

En su lugar, utilice bcrypt. PBKDF2 tampoco es malo.

  

La mayoría de los sitios web utilizan md5 o sha1 (¿verdad?), así que esto es lo que un hacker estaría esperando. De este modo, el método AES es más seguro.

Incluso si la mayoría de los sitios web usan MD5 o SHA1, cambiar a AES simplemente porque no se usa habitualmente allí no lo haría más seguro, eso es security by obscurity , que generalmente no contribuye de manera efectiva a aumentar la seguridad; será mucho más seguro usar un buen algoritmo (que está bien probado para el propósito dado) y documentarlo públicamente, que usar un algoritmo del cual no puede estar seguro de si es bueno, y no decir que está usándolo.

En este momento puedo pensar en las siguientes desventajas posibles al usar AES o cualquier otro algoritmo de cifrado como este:

1. Los algoritmos de cifrado generalmente no están diseñados para evitar colisiones: como se señala en los comentarios a continuación, podría no ser un problema debido al comportamiento pseudoaleatorio esperado del cifrado de bloque. Pero aún así, estás usando un algoritmo de cifrado para algo para lo que no fue diseñado.
2. Es imaginable que haya ataques a los algoritmos de encriptación que son mucho más fáciles de hacer si uno sabe que el texto claro y la contraseña son en realidad una y la misma (en caso de que el hecho de que el algoritmo está usando sea de alguna manera, no sea eso es poco probable dado que, por ejemplo, se discute aquí).
3. Los algoritmos de cifrado producen datos que, en muchos casos, varían con la longitud del texto claro. Eso significa que el texto cifrado contiene información sobre la duración de la contraseña. En el caso de AES, esto es un múltiplo de 16 bytes por lo que puedo decir ; los valores hash, por otro lado, tienen un tamaño fijo (por ejemplo, 160 bits / 20 bytes para SHA1); lo que significa que un pirata informático potencial tiene la posibilidad de obtener más información de un texto cifrado que de un valor hash.
4. En la criptografía, por lo general, siempre es menos seguro. Cocine algo por su cuenta (que luego es probable que solo use usted) que usar algo que ya está bien probado y en la comunidad desde hace mucho tiempo (lo que significa que tuvo tiempo para ser inspeccionados minuciosamente por varios criptoanalistas).
5. Desea asegurarse de que el algoritmo de hash de su contraseña sea lento, de modo que los posibles atacantes tengan dificultades para ingresar en su sistema. Una forma de lograr esto es, por ejemplo, realizar iterativamente el hash en múltiples rondas, como lo hace, por ejemplo, PKBDF2. Para obtener más detalles, consulte enlace

Un problema inmediato que veo con este enfoque es la longitud de la clave fija de AES. Usando AES-128, uno estaría restringido a 16 bytes de la contraseña. ¿Qué pasa con las contraseñas más largas o frases de contraseña largas?

Para adaptarse a cualquier longitud de contraseña, necesitarías una función hash, así que regresa al punto inicial.

Tenga en cuenta que existen formas bien estudiadas y seguras * de convertir un cifrado de bloque en una función hash, llamados modos PGV como Davies-Meyer, Matyas-Meyer-Oseas o Miyaguchi-Preneel.

(*) Para una definición apropiada de "seguro".

Sin embargo, considera esto:

Entro a su sitio y obtengo acceso suficiente para notar que tiene las claves AES configuradas para su sistema, solo lo que parece "encriptado" son sus contraseñas ... adivine qué voy a hacer.

Los mantendría con hash, deja mucho menos espacio para raspar fácilmente toda la base de datos de contraseñas.

Además de eso, como propietario de un sitio, NO QUIERO descifrar las contraseñas de mis usuarios en primer lugar, de lo contrario, la opción de "recuperar contraseñas" se convierte en una posible característica que los usuarios más avanzados pueden pedir, y técnicamente, podemos hacerlo porque el sistema subyacente se construye utilizando un sistema de encriptación en lugar de un sistema de hashing (por una mala razón, pero los desarrolladores de software tratan con solicitudes como estas).

Principalmente: cuando se trata de seguridad, no intente hacer algo extraño y de forma inmediata, es probable que se escriba un gran agujero de seguridad porque no podrá hacer una gran cantidad de investigación a un equipo de personas que trabajan. en un algoritmo para un propósito específico tendría que hacerlo.

Hay MAC (códigos de autenticación de mensajes) construidos a partir de cifrados de bloque; el más conocido es probablemente CBC-MAC . Tiene problemas en comparación con un hash-mac, en particular:

  

Dado un cifrado de bloque seguro, CBC-MAC es seguro para longitud fija   mensajes Sin embargo, por sí mismo, no es seguro para longitud variable   mensajes Un atacante que conoce la etiqueta de mensaje correcta (es decir, CBC-MAC)   los pares (m, t) y (m ', t') pueden generar un tercer mensaje m '' cuyo   CBC-MAC también será t '.

     

[...]

     

Este problema no se puede resolver agregando un bloque de tamaño de mensaje (por ejemplo, con el fortalecimiento de Merkle-Damgård) y, por lo tanto, se recomienda usar un modo de operación diferente, por ejemplo, CMAC para proteger la integridad de los mensajes de longitud variable.

La respuesta más breve: la seguridad de un MAC creado a partir de un cifrado de bloque depende de cómo lo construyas. Una construcción ingenua seguramente tendrá defectos importantes.

La respuesta correcta es: Realmente no importa en absoluto.

En el caso de las contraseñas, el único ataque práctico es probar una lista de contraseñas hasta que encuentre la correcta por fuerza bruta. Nadie intentará atacar SHA1 ni AES directamente para hacer eso. Incluso en el punto actual de investigación, atacar SHA1 sería diez mil veces más fácil que AES, ambos son completamente imposibles (para revertir los hashes de contraseña porque las colisiones no son importantes aquí) Y como un investigador encuentra otra forma de atacar al otro algoritmo, las probabilidades podrían revertirse el próximo año.

Lo que podría importar es qué tan rápido derive su hash / cifre su contraseña. Pero si por ejemplo SHA1 es más rápido y quieres que sea más lento (para defenderse de los ataques de fuerza bruta), puedes hash varias veces.

Lo que un pirata informático "espera" no es tan relevante, hacer que algo "inesperado" sea solo oscuridad. Es como decir "Revertir todas las letras de contraseña, ahora es más seguro". No lo sera Si el hacker puede acceder a su base de datos de contraseñas, ¿cómo puede estar seguro de que no tiene acceso a la función de derivación de hash de su contraseña?

Una falla cuando se "encripta una contraseña consigo misma": la longitud del texto cifrado podría dar al atacante una pista sobre la longitud de la contraseña. Eso es horrible.

En cualquier caso, debe agregar la contraseña, preferiblemente con algo exclusivo para el usuario.

El hecho de que haya diseñado un algoritmo inusual no lo hace seguro. Los algoritmos "hechos por sí mismos" son peligrosos, porque nadie ha realizado un análisis criptográfico de ellos.

Como @Thomas Pornin escribió anteriormente, AES no fue diseñado para ser resistente a las colisiones. Además, AES es relativamente rápido, lo que simplifica los ataques.

SHA1 está diseñado para ser resistente a las colisiones, pero SHA1 también está diseñado para ser muy rápido, ya que su propósito es generar hashes de grandes volúmenes de datos o archivos en poco tiempo. Su propósito no es evitar ataques a las contraseñas con hash.

Si desea generar un hash de contraseña que sea resistente a diferentes tipos de ataques, considere la extensión de la contraseña. Dependiendo de su pila de tecnología y de las bibliotecas disponibles, considere bcrypt, scrypt, argon2 .