¿Los clientes no mejoran la seguridad de HTTP Digest Auth?

7

Hasta donde entiendo la respuesta en enlace , la intención de los clientes es evitar que los atacantes amorticen los costos de la fuerza bruta cálculos de hash al poder reutilizar los resultados de los cálculos

  • para múltiples usuarios y / o
  • para múltiples servidores

Sin embargo, incluso en la variante de Autenticación Digestiva más simple (qop = none), el username y el realm (supuestamente único por servidor) y el nonce (más que solo único por servidor) están incluidos en el datos que se vuelven (generalmente MD5) hash.

¿Esto ya no hace que sea imposible reutilizar los hash precomputados en los usuarios / servidores?

Por lo tanto, una referencia de cliente solo se agregaría a la seguridad, si enlace es correcto:

  

Se sabe que la capacidad de elegir el nonce hace que el criptoanálisis sea mucho más fácil [8].

Pero esa misma sección continúa diciendo

  

Sin embargo, actualmente no se conoce ninguna forma de analizar la función unidireccional MD5 utilizada por Digest utilizando texto sin formato elegido.

Esta es una declaración de 1999. Desde entonces, se han publicado varios ataques de colisión para MD5, pero ninguno de los cuales ayudaría en este caso, si no me equivoco.

¿Qué me estoy perdiendo?

Actualizar Creo que tiene sentido explicar de qué estamos hablando exactamente. En la forma más básica de autenticación implícita, el cliente calcula y envía al servidor el resultado de lo siguiente:

MD5(MD5(username + ":" + REALM + ":" + password)
    + ":" + NONCE + ":" +
    MD5(http-method) + ":" + uri))

A excepción de la contraseña, todos los valores también se envían en texto sin formato.

Para hacerlo más claro, las variables cuyos valores son establecidos por el cliente son minúsculas , mientras que las variables que el cliente recupera del servidor están en mayúsculas . (Esto hace que mi falacia de 'reino y nonce' arriba, señalada por David Wachtfogel de inmediato sea obvia, ya que un MITM puede elegir libremente esos valores en mayúsculas, asumiendo que el reino no está controlado por el cliente, que, a juzgar por la "sofisticación" I visto en la mayoría de las contraseñas de administrador, sería la norma, en lugar de la excepción).

Por cierto, el valor del uri se supone que es un uri absoluto , como http://servername/path?query , y por lo tanto sería único a nivel mundial, sin embargo, eso depende de la implementación del cliente y mientras que Opera lo implementa de esa manera , las versiones de Chrome, IE, Firefox probé no y, en lugar de eso, solo usamos '/ path? query' (por favor, esto es en violación de enlace ).

Entonces, si una tabla precomputada sería reutilizable en todos los servidores depende de la implementación del cliente, y si MITM puede elegir, por supuesto preferirá los navegadores más débiles a Opera, si tiene una tabla precomputada.

    
pregunta Eugene Beresovsky 16.10.2012 - 09:49
fuente

2 respuestas

6

Como se describe en la respuesta de Thomas Pornin citada en esta pregunta, el objetivo del cliente es evitar una ataque de texto simple elegido en el que el atacante se hace pasar por el servidor y elige el desafío. En tal situación, el atacante también puede elegir el reino (ya que esto proviene del servidor), por lo que el hecho de que el reino esté oculto como parte de la respuesta no evita completamente este ataque. Solo si el usuario está atento y verifica que el reino sea el esperado, esto evitará el ataque.

El nombre de usuario ayuda, ya que requiere que el atacante construya una tabla hash precomputada, como una tabla de arco iris, por nombre de usuario. El problema es que los nombres de usuario no son únicos a nivel mundial: el mismo nombre de usuario existirá en muchos servidores diferentes. De hecho, algunos nombres de usuario son extremadamente comunes y es probable que aparezcan en la mayoría de los servidores; un ejemplo clásico es "admin".

Para que un atacante pueda hacer lo siguiente:

  1. Una vez: cree una tabla hash precomputada para username="admin", realm = X y challenge = Y (usando cualquier valor para X e Y)
  2. Intercepta las conexiones a cualquier servidor que el atacante quiera atacar
  3. Si alguien se conecta al servidor con el nombre de usuario "admin", envíe real = X y desafío = Y
  4. Busque la respuesta en la tabla hash precomputada para revelar la contraseña

El cliente no evita este tipo de ataque; ya que el atacante no controla y no puede predecir esta situación, el atacante no puede construir la tabla de hash precomputada.

    
respondido por el David Wachtfogel 16.10.2012 - 13:10
fuente
2
  

el nombre de usuario y el reino (supuestamente único por servidor)

Esto no es correcto. El reino es un valor especificado por el proveedor de servicios para describir el reino de protección, por lo que es solo un nombre, no un identificador global.

En su segunda cita, creo que se refieren a la "unidireccional" de MD5 que no se rompe. La forma más efectiva de encontrar una preimagen (es decir, pasar del valor Y = MD5 (x) para encontrar x) requiere 2 operaciones 123.4 .

el cnonce "es una cadena opaca proporcionada por el cliente y utilizada tanto por el cliente como por el servidor para evitar los ataques de texto sin formato elegidos, para proporcionar autenticación mutua y para proporcionar cierta protección de integridad del mensaje." [RFC ] Junto con el nonce, facilita la autenticación mutua sostenida: la autenticación del cliente al servidor y viceversa.

    
respondido por el Henning Klevjer 16.10.2012 - 10:00
fuente

Lea otras preguntas en las etiquetas