¿Es inseguro el uso del algoritmo de hashing md5 como método de autorización en una solicitud HTTP POST?

Esta idea levanta banderas rojas en mi cabeza por varias razones:

1. MD5 se rompe de una manera que hace posible que un atacante calcule un hash en colisión, de manera que md5(a + b) == md5(a + c) sin tener que conocer b . En este caso, a es su ID de usuario y b es su secreto. Como tal, MD5 es una mala elección aquí. Los hashes de la familia SHA también son una mala elección, ya que dependen de la misma construcción y sufren el mismo problema. Actualización: No, me equivoqué. MD5 no es tan roto como pensaba. En cualquier caso, los siguientes puntos son verdaderos ...
2. Si confía en MD5 para la resistencia a la fuerza bruta, tendrá problemas. MD5 corre demasiado rápido para ese tipo de cosas. Debe utilizar un KDF lento como PBKDF2 o bcrypt. Aun así, esto parece ser un uso extraño para un hash o KDF.
3. La sal parece no servir para nada aquí. Las sales se utilizan para prevenir ataques de precomputación, como tablas de arco iris y bases de datos hash. Si el objetivo es prevenir los ataques de repetición, la sal no te ayudará aquí. Un atacante podrá volver a reproducir sus mensajes de autenticación.
4. Un atacante puede modificar la solicitud en tránsito, realizando un ataque de hombre en el medio. Al hacerlo, es libre de alterar arbitrariamente estos mensajes.

La única forma de hacerlo correctamente es usar HTTPS (es decir, TLS) para la conexión. Esto proporciona autenticidad y confidencialidad, y evita los ataques de reproducción.

¿El ID de usuario o la frase de contraseña caducan después de un solo uso? Si no, ¿qué evitaría que un atacante reutilice el hash MD5 (o cualquier hash) de esa información para realizar una solicitud diferente? ¿Por qué incluso molestarse en picar? Respuesta: No, no es seguro.

En términos generales, diría que no.

Estás confiando en esta propiedad: un atacante conoce Y y Hash(X+Y) pero no sabe X . No debe poder determinar H(X+Z) para cualquier Z que no sea igual a Y .

El problema es que MD5 no tiene esta propiedad y no fue diseñado para resistir este tipo de ataque. De hecho, ningún hash Merkle-Damgård puede resistir este tipo de ataque.

La API de Flickr asumió que MD5 tenía esta propiedad diezmada por un ataque de este tipo .

Tal como lo describe, las cosas van de la siguiente manera: su sitio web necesita reenviar una solicitud a otro sitio web, y este último solo aceptará si la solicitud viene con un "blob de autenticación", que es el hash de un identificador de usuario y su contraseña. Este blob (el resultado de MD5) es entonces "la contraseña", ya que demostrarlo es suficiente para otorgar acceso; esto es muy débil con respecto a los espías, ya que espiar en la línea sería suficiente para recuperar el blob, momento en el que el atacante podría adjuntarlo a cualquier solicitud que quisiera enviar.

Si el protocolo no es como se describe anteriormente, pero vincula el hash con los datos solicitados (por ejemplo, el hash no se calcula sobre la ID de usuario y la frase de acceso solo , pero también en la ruta de los datos solicitados), entonces la autenticación es un poco menos débil, pero todavía no es buena; Exhibiría los dos pecados clásicos:

1. Eavesdropping revela un valor de hash calculado sobre la frase de contraseña y algunos datos conocidos, lo que permite un ataque de diccionario sin conexión : el atacante simplemente "intenta" algunas contraseñas potenciales hasta que se encuentra una coincidencia con el hash observado. Como una GPU de 150 $ puede calcular miles de millones de instancias de MD5 por segundo, incluso las contraseñas de fuerza media no resistirán el ataque por mucho tiempo.

2. La comunicación completa no está protegida, por lo que los intrusos observarán los datos en sí mismos (los datos para los cuales se usó la autenticación de acceso, por lo que presumiblemente los datos sensibles ). Los atacantes activos podrán manipular la solicitud y la respuesta de manera arbitraria.

El canje se logra con el uso de SSL , que soluciona ambos problemas.