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?