Prevención de la fijación de sesión: ¿MAC o Hash?

0

Esta publicación del blog describe un método para prevenir los ataques de fijación de sesión (en ASP.Net en particular). La idea es que el ID de sesión debe estar vinculado a la identidad del usuario de manera verificable, lo que significa que un ID de sesión determinado no puede ser válido tanto para el atacante como para la víctima. Sus usos de construcción:

select random nonce
session_id = nonce || MAC(nonce || username).

Para una aplicación que se ejecuta en un clúster, la distribución o el cambio de la clave MAC pueden ser inconvenientes. ¿Qué se pierde si el MAC se reemplaza por un hash sin clave?

select random nonce
session_id = nonce || Hash(nonce || username).

Significa que un atacante puede generar identificadores de sesión que son válidos para una identidad determinada, pero aún así es cierto que un identificador de sesión no será aceptado tanto para el atacante como para la víctima. ¿Hay alguna debilidad con este enfoque?

    
pregunta bmm6o 03.02.2015 - 18:58
fuente

1 respuesta

1

P1: Prevención de la fijación de sesión: ¿MAC o hash?

Q2: ¿Qué se pierde si el MAC se reemplaza por un hash sin clave?

P3 - ¿Existe alguna debilidad con este enfoque (de reemplazar MAC con un hash)?

Usted identificó el inconveniente de la administración de claves con el uso de MAC en múltiples servidores, mientras que con el hash sin clave, el único inconveniente es un mayor riesgo de falsificación de sesión debido a la naturaleza pública de una función de hash. Entonces, en términos de la opción más segura, la opción MAC es mejor para prevenir sesiones forjadas. Sin embargo, en ambos casos, como se señaló, la fijación de la sesión todavía puede ocurrir. Otros enfoques que he visto para fortalecer la identificación de la sesión es ajustar la caducidad de la sesión e incluir el agente de usuario como entrada a la función MAC. Creo que Q1, Q2 y Q3 están afirmando o asumiendo parcialmente que el uso de MAC en la creación de ID de sesión es la "solución" para evitar la fijación de la sesión. Creo que es importante tener en cuenta un conjunto integral de estrategias para evitar la fijación de la sesión. Sin embargo, un problema muy importante en el entorno ASP.Net es no reutilizar los identificadores de sesión antiguos después de un usuario, lo cual es una gran vulnerabilidad para los ataques de reparación de sesión.

Consulte enlace

    
respondido por el James Knight 23.07.2016 - 19:21
fuente

Lea otras preguntas en las etiquetas