Fallo en la autenticación del resumen HTTP

Question

Fallo en la autenticación del resumen HTTP

#1 de Steffen Ullrich (2 votos)

2

Estoy trabajando en mi libro de texto y encontré esta pregunta:

A continuación se muestra el formato del mensaje para que una respuesta del navegador acceda a una página web protegida por contraseña mediante la autenticación de resumen HTTP.

GET URI HTTP/1.1
Host: URL
...
Authorization: Digest username="UserName", realm="Realm", nonce="Nonce",
uri="URI", algorithm=MD5, response="Response", qop=QoP, nc=NonceCount,
cnonce="ClientNonce"

¿Cómo validará el servidor esta respuesta?

Se me ocurrió este esquema:

    1. Use UserName and Realm to retrieve D1 =
       md5sum(Username:Realm:Password) from the password file.

    2. Compute D2 = md5sum(GET:URI).

    3. Compute r = md5sum(D1 : Nonce:NonceCount:ClientNonce:QoP:D2).

    4. If r == Response, authentication succeeds and return the content of
       URI; otherwise authentication fails and return an error code.

¿Es correcto o hay algún defecto en mi método?

Lo único en lo que puedo pensar es que un atacante de Man in the Middle podría decirle a los clientes que usen la autenticación de acceso básico porque la autenticación resumida no proporciona ningún mecanismo para que los clientes verifiquen la identidad del servidor. También puede ser vulnerable a los ataques de reproducción, es decir, si el cliente puede reproducir el resumen del mensaje creado por el cifrado, el servidor permitirá el acceso al cliente.

authentication http man-in-the-middle md5

pregunta fartsunknown 15.10.2015 - 21:08

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication http man-in-the-middle md5

¿Qué certificaciones necesito para convertirme en un analista de malware? [cerrado] Asegurar la API REST sin enviar o almacenar credenciales claras

score 2 · Answer 1

Se me ocurrió este esquema:

La autenticación implícita se define en RFC 2617 , así que consulte esta documentación en lugar de crear su propio esquema. .

También puede ser vulnerable a los ataques de reproducción ...

El nonce establecido por el servidor se utiliza para defenderse contra los ataques de reproducción, es decir, solo se aceptan las respuestas que coincidan con el nonce impredecible.

¿Cuáles podrían ser las fallas entonces? No estoy seguro de que el esquema que utilicé sea perfecto.

Aunque Digest resuelve el problema de autenticar al cliente a través de un canal inseguro, hace necesario almacenar las contraseñas en el servidor de forma sencilla o equivalente para poder verificar los datos enviados por el cliente. Esto desplaza el problema de vulnerabilidad del transporte de datos al servidor. Y, en efecto, le permite a un atacante no comprometer una sola cuenta pero zillions a la vez .

Lo que significa que debería usar mejor TLS para asegurar el canal y mantener la contraseña almacenada en un seguro en forma irreversible , para que un atacante no pueda comprometer cuentas fácilmente y en masa. Además, esto resuelve el problema de falta de identificación del servidor.