Sesiones autenticadas y Man in the middle

Question

Sesiones autenticadas y Man in the middle

#1 de martinstoeckli (1 votos)
#2 de user3119 (1 votos)

1

Veo muchos sitios web (incluido Stackoverflow) que utilizan este mecanismo de autenticación:

El cliente se autentica bajo HTTPS y recupera un ID de sesión.
El cliente vuelve a HTTP y accede a las páginas seguras mediante HTTP, pasando el ID de sesión para demostrar que se realizó la autenticación.

¿Cuál es el punto de usar HTTPS para proteger la autenticación si el usuario intermedio puede simplemente robar el ID de sesión resultante y actuar como el cliente autenticado? Entiendo que la sesión finalmente caducará, pero eso aún le da al atacante una ventana de oportunidad bastante larga para montar un ataque.

authentication man-in-the-middle session-management

pregunta Gili 25.05.2014 - 17:19

fuente

2 respuestas

1

simplemente puede evitar la pérdida de nombre de usuario / contraseña. En su escenario MITM puede evitar la seguridad. en otras palabras, engañar a los usuarios.

sin embargo, puede haber alguna mitigación, como que la ID de sesión es por IP / País. así que si alguien de otra página de solicitud de IP (probablemente alguien que haya MITMado el ID), la sesión caducará.

respondido por el user3119 25.05.2014 - 19:47

fuente

Lea otras preguntas en las etiquetas authentication man-in-the-middle session-management

Perforación de orificios de cortafuegos [cerrado] VPN - ¿Certificados de cliente únicos? [duplicar]

score 1 · Accepted Answer

Como el identificador de sesión se transfiere a una conexión HTTP no segura, un atacante podrá hacerse pasar por el usuario. Lo que él no sabe es la contraseña del usuario, el inicio de sesión se realiza con HTTPS.

Las contraseñas de los usuarios deben protegerse incluso mejor que el acceso a un sitio, porque a menudo los usuarios reutilizan sus contraseñas en diferentes sitios. Con esa contraseña, otros sitios (más importantes) también se ven comprometidos.

En otras palabras, al cambiar entre HTTP y HTTPS usted pone en peligro solo su propio sitio, y el envío de contraseñas a través de HTTP también pone en peligro otros sitios. En el caso de StackOverflow, pondría en peligro todos los sitios conectados con la cuenta OpenId de los usuarios.