ataques de texto plano elegidos contra MD5 y SHA1

El objetivo del atacante es adivinar la contraseña. Al observar el mensaje de autenticación, el atacante ya aprende lo suficiente como para "probar" las contraseñas en casa (es decir, un "ataque de diccionario sin conexión"), pero eso no es de lo que RFC 2617 está hablando en ese momento. Más bien, se concentra en la idea de un atacante que se hace pasar por el servidor y, por lo tanto, alimenta los "servidores" de su elección al cliente. El cliente responde a tal nonce mediante el hashing de nonce del servidor, del nonce del cliente y de la contraseña juntos (omito voluntariamente los detalles aquí). El atacante puede entonces tratar de explotar alguna debilidad interna de la función hash para volver a calcular la contraseña de lo que el cliente envió. Lo que el RFC 2617 intenta decir es que omitir el nonce cliente solo puede facilitar las cosas para el atacante (al menos probablemente no más difícil, y heurísticamente más fácil) - como corolario, usar un nonce puede ayuda para proteger al cliente en caso de que la función hash sea inestable; un cliente no hará ningún daño adicional.

Ahora no se conoce ninguna debilidad explotable de MD5, cuando se usa en la autenticación de acceso implícito como se describe en RFC 2617. A pesar de que MD5 ha mostrado una gran descamación con respecto a la resistencia a la colisión, que es otra propiedad de seguridad distinta La función debería tener (y que MD5 no tiene). Así que la protección ofrecida aquí por el cliente es solo hipotética. Pero, como dije, tampoco hace daño.

Esa sección de la RFC está haciendo algunas afirmaciones dudosas, y no está bien escrita. Esto es lo que creo que debería haber dicho.

1. Si permites que el atacante controle parte de la entrada a una función hash, entonces debes pensar si esto habilita los ataques de texto simple elegidos en la función hash. Si el cliente no proporcionó ningún tipo de error, entonces uno podría preocuparse de que un servidor malintencionado pudiera elegir su servidor de manera malintencionada en un intento de montar algún tipo de ataque de texto simple elegido en la función hash.

   Afortunadamente, las funciones hash actuales están diseñadas para ser seguras contra los ataques de texto sin formato elegido, por lo que esta preocupación no es realmente un riesgo en la práctica.

   Por otra parte, si quieres ser realmente cauteloso, supongo que podrías intentar reducir el número de oportunidades para este tipo de ataques al incluir un número aleatorio elegido por el cliente. De esta manera, incluso si el servidor es malicioso, se garantiza que formará parte de la entrada a la función hash que es aleatoria, no controlable por el atacante y no predecible por el atacante. No está claro si esto realmente proporciona algún beneficio (probablemente es innecesario), pero no puede hacer daño.

   Vea la respuesta de @Tomas para más detalles.

2. En general, es una buena práctica de ingeniería que ambos puntos finales contribuyan con su propia fuente aleatoria. Por ejemplo, en algunas situaciones, esto ayuda a prevenir ciertos tipos de ataques de reproducción en los que un punto final es malicioso.

   No sé si dejar de lado el cliente en realidad permitiría algún tipo de ataque de reproducción inteligente en RFC2617, pero ¿por qué arriesgarse? Si hay una modificación simple que puedo hacer que descarta toda una clase de posibles ataques, esa modificación parece atractiva. Cualquier cosa que me evite tener que pensar mucho sobre ataques sutiles (y posiblemente pasar por alto uno, que es catastrófico) se siente como algo bueno.

3. En el caso de RFC2617, la inclusión de un cliente evita los ataques de precomputación (por ejemplo, ataques de intercambio de tiempo / espacio, "tablas de lluvia" y similares) cuando el servidor es malicioso. Consulte la respuesta de @ ixe013 y mi comentario para obtener más detalles sobre esto.

Sí, sigue siendo un problema con SHA1. Es irrelevante del algoritmo de hashing real, aparte de que el atacante necesitará más espacio para almacenar las tablas de búsqueda, y tal vez un poco más de tiempo para calcularlas.

El resumen es un hash del nombre de usuario, la contraseña, el valor de nonce dado, el método HTTP y el URI solicitado (RFC2617). El atacante los conoce a todos (pero la contraseña) y, por lo tanto, puede preparar una tabla de búsqueda de antemano. Una tabla de este tipo no puede ser precomputada, ya que el cliente agrega su propia nonce (cnonce), desconocida previamente por el atacante.