Resumen: seguridad de sesiones vinculadas al dispositivo
- La brecha: La MFA se trata como la línea de meta para la seguridad de cuentas, pero en el momento en que se completa la autenticación deja de ayudar, y cada token de sesión robado tras un reto MFA válido sigue funcionando desde cualquier dispositivo en Internet.
- Lo que cside ve: Las sesiones vinculadas al dispositivo de cside generan una huella derivada del hardware a partir del renderizado de GPU, la entropía de canvas, las métricas de fuentes y la salida WebGL que sobrevive al borrado de cookies, al modo incógnito y a las VPN, porque se recalcula desde el dispositivo en lugar de residir en el almacenamiento de cookies.
- La decisión: Si tu postura frente al account takeover termina en la MFA, decide este trimestre si un fallo de XSS o una herramienta man-in-the-browser que se lleve un token de sesión válido es un riesgo que estás dispuesto a asumir por completo.
¿Poco tiempo? Consulta la detección de robo de cuentas de cside. Cubre todo lo de abajo en un solo despliegue.
Una sesión vinculada al dispositivo es una sesión autenticada ligada al dispositivo concreto que la creó. Si el token de sesión se presenta después desde un dispositivo distinto, se detecta la discrepancia de huella y la sesión se rechaza o se envía a una verificación adicional. Eso cierra una brecha que la mayoría de la autenticación deja abierta: la ventana posterior al inicio de sesión, cuando un token válido puede robarse y reutilizarse desde otro lugar.
| Escenario | Qué hace el MFA | Qué hace la vinculación al dispositivo |
|---|---|---|
| Robo de credenciales antes del inicio de sesión | Exige al atacante un segundo factor | Espera hasta que exista una sesión que vincular |
| El atacante completa el MFA en su dispositivo | Permite el acceso porque se superó el desafío | Vincula la sesión nueva al dispositivo del atacante, por lo que no corrige el acceso comprometido |
| Robo de un token de sesión válido después del MFA | No ejecuta un nuevo desafío de inicio de sesión | Detecta una discrepancia de huella cuando el token se reproduce desde otro dispositivo |
| Petición válida desde el dispositivo original | Ya ha completado su comprobación de acceso | Hace coincidir la huella guardada y permite que la sesión continúe |
La brecha posterior a la autenticación que cierra la vinculación al dispositivo
El MFA protege el evento de inicio de sesión. Confirma que la persona que envía las credenciales también controla un segundo factor en ese momento. Una vez completada la autenticación y emitido un token de sesión, el MFA ha cumplido su función. El token en sí es una credencial de portador, así que cualquier parte que lo tenga puede presentarlo al servidor y obtener una respuesta autenticada.
Los tokens de sesión se roban por varias vías: cross-site scripting que lee las cookies, proxies man-in-the-browser que capturan los tokens en el momento en que se establecen, almacenamiento de dispositivo robado e ingeniería social que engaña a los usuarios para que los expongan. En cada caso el atacante acaba con un token válido que se emitió tras un desafío MFA legítimo. El desafío ya quedó atrás. El token robado sigue funcionando.
Las sesiones vinculadas al dispositivo cierran esa brecha. Incluso cuando un atacante tiene un token válido, usarlo desde un dispositivo distinto produce una discrepancia de huella que el servidor puede detectar. La sesión solo es de confianza cuando procede del dispositivo que la creó.
Cómo funciona técnicamente la vinculación al dispositivo
La sesión se vincula en el momento de la autenticación. Cuando un usuario inicia sesión, la huella del dispositivo de esa sesión (derivada de señales del navegador y del hardware) se registra junto con el token de sesión en el almacén de sesiones del servidor.
En cada solicitud posterior que presenta el token, el servidor compara la huella actual con la registrada en el inicio de sesión. Si coinciden, la solicitud continúa. Si no, la sesión se invalida o se dispara una verificación adicional.
La huella que se usa para la vinculación tiene que ser estable y derivada del hardware. Los identificadores basados en cookies no sirven, porque se pueden copiar junto con el token de sesión. Un atacante que roba una cookie de sesión también puede robar cualquier ID de dispositivo basado en cookies que esté en el mismo almacén. Una huella a nivel del navegador derivada del renderizado de la GPU, la entropía del canvas, las métricas de fuentes y la salida de WebGL no se puede extraer del almacenamiento de cookies, porque no está guardada ahí. Se recalcula a partir del hardware en cada sesión.
Las sesiones vinculadas al dispositivo de cside generan una huella derivada del hardware al crear la sesión y la devuelven junto con el token de sesión a través de su API. Tu servidor registra la huella con la sesión. En cada solicitud protegida, el script ligero de cside recalcula la huella de la sesión actual, y tu aplicación la compara con el valor almacenado. cside no reemplaza tu token de sesión. Te da una señal de dispositivo lo bastante fuerte como para saber si el token se está reutilizando en un lugar donde no debería.
De qué protege la vinculación al dispositivo
Secuestro de sesión tras un XSS. Un fallo de cross-site scripting que permite a un atacante leer las cookies de sesión no entrega una sesión utilizable cuando esa sesión está vinculada al dispositivo. Reutilizar el token robado desde la máquina del atacante produce una discrepancia de huella.
Captura de sesión man-in-the-browser. El malware de navegador que intercepta una sesión autenticada captura el token pero no la señal del dispositivo, porque la señal se calcula a partir del hardware de la víctima. El token robado no coincide con la huella del atacante.
Uso compartido de credenciales tras la autenticación. Cuando un usuario legítimo entrega su token de sesión a un compañero (algo habitual en herramientas empresariales donde añadir una licencia requiere acción de un administrador), la sesión compartida muestra una discrepancia de dispositivo. Este es el problema del uso compartido de cuentas aplicado en la capa de sesión en lugar de la capa de inicio de sesión.
Viaje imposible. Una sesión creada en Londres y presentada después desde un dispositivo con características de red de una geografía distinta, dentro de una ventana de tiempo demasiado corta para un viaje físico, es detectable a través del cambio de huella combinado con las señales de red.
Cómo encajan las sesiones vinculadas al dispositivo y el MFA
La vinculación al dispositivo protege la sesión después de la autenticación. El MFA protege el evento de inicio de sesión durante la autenticación. Cubren puntos distintos del ciclo de vida de la sesión, y una postura completa frente a la apropiación de cuentas necesita ambos.
Un atacante que vence el MFA mediante un SIM swap o fatiga de notificaciones push y se autentica con éxito recibe un token de sesión en su propio dispositivo. La vinculación al dispositivo en esa sesión no ayuda, porque el dispositivo del atacante es el origen de la sesión. El MFA es el control que importa en esa fase.
Un atacante que observa a un usuario legítimo completar el MFA y luego roba el token de sesión mediante XSS es frenado por la vinculación al dispositivo, porque su huella no coincide con el origen de la sesión. El MFA ya se completó y no ofrece nada en este punto.
Junta las dos y la cobertura queda clara. El MFA frena en el inicio de sesión a los atacantes que carecen de credenciales válidas o no pueden satisfacer el segundo factor. La vinculación al dispositivo frena después del inicio de sesión a los atacantes que obtuvieron una sesión válida por otra vía.
