Pregunta sobre el papel SessionLock

Question

Pregunta sobre el papel SessionLock

#1 de Ben Adida (3 votos)
#2 de frankodwyer (2 votos)

4

Hace algún tiempo hubo una gran confusión sobre Firesheep: al escuchar el tráfico de wifi, su sesión de inicio de sesión puede ser robada, lo cual es muy malo porque ahora alguien puede, por ejemplo. enviar correos electrónicos en su nombre. Algunas personas dijeron que el uso de SSL para todo el sitio era la única solución. Pero no pensé que esto fuera cierto: si puede mantener la contraseña o el equivalente almacenado en el lado del cliente, y nunca lo envía al servidor, sino que autentica todas las solicitudes que realiza con esta contraseña, entonces nadie puede hacerse pasar por usted (a menos que ellos saben tu contraseña). Por ejemplo, cuando realiza una solicitud HTTP req , en su lugar, realiza la solicitud r + "?hmac=HMAC(password, req)" para demostrar que conoce la contraseña.

Luego encontré un documento sobre un protocolo llamado SessionLock , cuyo objetivo es resolver el mismo problema. Es un poco diferente de lo que describí anteriormente, y tengo algunas preguntas al respecto.

Primero, ¿por qué establecen un secreto compartido a través de SSL o usando el protocolo Diffie-Hellman, cuando ya hay un secreto compartido disponible (la contraseña o una versión con hash de la contraseña)?

Segundo, sobre la versión que usa Diffie-Hellman que dicen:

Si el navegador pierde su secreto, puede volver a ejecutar una clave Diffie-Hellman intercambiar con el servidor, utilizando un número de llamadas XMLHttpRequest.

¿Alguien puede explicar cómo funciona esto? Supuestamente el lado del cliente no guardó la contraseña, y también perdió el secreto compartido. Entonces, por lo que veo, el lado del cliente no sabe nada, pero él es capaz de restablecer un secreto compartido que se puede usar para hacer cosas autenticadas. ¿No podría un atacante hacer exactamente lo mismo? ¿Qué me estoy perdiendo?

authentication key-management cryptography tls

pregunta Jules Jacobs 18.04.2011 - 16:53

fuente

2 respuestas

2

Diffie-Hellman es suficiente para establecer un secreto compartido de la nada si no estás preocupado por los ataques activos, y de acuerdo con el periódico, no hacen ningún tipo de defensa contra estos. Así que estás en lo correcto, el atacante puede hacer lo mismo, pero solo con un ataque activo, no solo por espionaje.

El protocolo es vulnerable a los ataques activos en general, de todos modos, aparte de esto, me parece (p. ej., el motor del cliente se sirve mediante JavaScript, que no está autenticado, por lo que puede introducir su propio código y subvertirlo todo) ).

En cuanto a la otra parte de su pregunta, ¿por qué acordar un nuevo secreto cuando ya tiene uno? En general, tiene sentido evitar usar una contraseña directamente como clave si puede, ya que es probable que el resultado sea vulnerable al diccionario. y ataques de fuerza bruta. Sin embargo, en este caso, probablemente lo hayan hecho de esa manera porque un atacante activo puede robar el secreto (aunque me parece que todavía pueden hacerlo debido al problema de JS que mencioné anteriormente).

respondido por el frankodwyer 25.04.2011 - 09:41

fuente

Lea otras preguntas en las etiquetas authentication key-management cryptography tls

¿Leyendo sobre seguridad por diseño? ¿Qué necesita un MCSE para aprender a dominar la seguridad de * nix?

score 3 · Accepted Answer

Técnicamente, podría usar la contraseña como el secreto compartido en SessionLock, pero luego el sitio web necesita almacenar la contraseña en forma clara. Entonces, como sugiere, podría usar el hash de contraseña, pero luego el hash de contraseña de repente se vuelve casi tan bueno como la propia contraseña, ya que saberlo es suficiente para configurar una sesión segura con el servidor. Así que esa es una buena razón para no usar el hash de contraseña.

Pero principalmente, mi objetivo de diseño, en SessionLock, era no enredar el método de autenticación con la seguridad de la sesión. ¿Qué hay de antes de iniciar sesión? Todavía no quiero que alguien me robe la sesión. ¿Y qué pasa con los sistemas que utilizan autenticación HTTP o alguna otra abstracción de comprobación y almacenamiento de contraseñas que generalmente dificulta que el código de su aplicación web obtenga los datos de la contraseña, incluso su hash? O un sitio web más grande donde el inicio de sesión ocurre en login.*.com , y luego se establece una cookie de sesión y eso es todo, los diversos service1.*.com , service2.*.com no tienen la contraseña real.

Por todas estas pequeñas razones, SessionLock no vincula su secreto compartido directamente a las credenciales.

Y como han mencionado otros comentaristas, ten cuidado. SessionLock solo evita que los atacantes de red pasivos roben su sesión. La carga útil todavía es legible para los intrusos y no tiene suerte contra los atacantes de red activos.