Google comenzó a ofrecer al público la tecnología Device Bound Session Credentials (DBSC) para los usuarios de Windows en el navegador Chrome 146, después de anunciarla por primera vez en abril de 2024. Está previsto que se amplíe a macOS en una próxima versión de Chrome. La tecnología aborda uno de los problemas de seguridad de sesiones más comunes: el robo de cookies que permite a los atacantes acceder a las cuentas sin necesidad de contraseñas.
El robo de sesiones suele producirse cuando el usuario descarga involuntariamente software malicioso. Después de ejecutarse, el programa puede extraer las cookies actuales del navegador o esperar a que el usuario inicie sesión en cuentas nuevas y, a continuación, enviar esos tokens a un servidor controlado por el atacante. Google señala que las familias de programas que roban información, como LummaC2, se han vuelto más sofisticadas en la recopilación de credenciales.
El riesgo de estas cookies aumenta debido a la duración prolongada de algunas de ellas, ya que los atacantes pueden utilizarlas para obtener acceso no autorizado a las cuentas y después recopilarlas, intercambiarlas o venderlas entre grupos delictivos. Además, el malware avanzado, una vez que obtiene acceso al dispositivo, puede leer los archivos y la memoria en los que los navegadores almacenan las cookies de autenticación. Por ello, Google considera que no existe un método fiable para impedir la extracción de cookies basándose únicamente en el software, independientemente del sistema operativo.
Vincular la sesión a una clave que no abandona el dispositivo
DBSC cambia este modelo al vincular criptográficamente la sesión de autenticación a un dispositivo específico. La tecnología utiliza módulos de seguridad respaldados por hardware, como el módulo de plataforma segura TPM en Windows y Secure Enclave en macOS, para crear un par único de claves pública y privada. La clave privada no se puede exportar del dispositivo.
El servidor no emite nuevas cookies de corta duración hasta que Chrome demuestra que posee la clave privada vinculada a la sesión. Como el atacante no puede robar esta clave, las cookies extraídas caducan rápidamente y dejan de ser útiles para acceder a las cuentas. Google afirma que ha observado una disminución significativa del robo de sesiones protegidas mediante DBSC desde el lanzamiento de una versión inicial del protocolo durante el año pasado.
Los sitios web, tanto grandes como pequeños, pueden adoptar sesiones vinculadas al hardware añadiendo puntos de conexión específicos de registro y actualización a sus sistemas de backend, manteniendo al mismo tiempo la compatibilidad con el frontend actual. El navegador se encarga de las operaciones criptográficas complejas y de la rotación de cookies en segundo plano, mientras la aplicación web sigue utilizando cookies estándar para acceder a sus servicios.
Proteger las sesiones sin rastrear al usuario
DBSC se diseñó teniendo en cuenta la privacidad. Cada sesión se basa en una clave independiente, lo que impide que los sitios utilicen estas credenciales para vincular la actividad del usuario entre distintas sesiones o entre varios sitios del mismo dispositivo. El protocolo tampoco envía al servidor identificadores del dispositivo ni datos de atestación, salvo la clave pública específica de la sesión, necesaria para demostrar la posesión de la clave privada.
Según Google, este intercambio limitado de información reduce los riesgos de utilizar la tecnología para rastrear al usuario entre sitios o crear una huella identificativa del dispositivo.
Un estándar abierto y en desarrollo continuo
DBSC se diseñó desde el principio como un estándar web abierto mediante el proceso del W3C y la adopción por parte de un grupo de trabajo de seguridad de aplicaciones web. Google colaboró con Microsoft en el diseño del estándar. También participaron numerosas plataformas web, entre ellas Okta, en los dos Origin Trials del año pasado y aportaron comentarios basados en las pruebas y el uso.
Google ofrece a los desarrolladores una guía de implementación, además de las especificaciones del protocolo, un repositorio de GitHub y una página para informar de errores o proponer funciones.
Las próximas áreas de desarrollo incluyen:
- Protección de la identidad federada: ampliar DBSC para permitir la vinculación entre distintos recursos, de modo que la sesión de la parte dependiente siga vinculada a la clave del dispositivo original utilizada por el proveedor de identidad durante todo el proceso de inicio de sesión único.
- Capacidades avanzadas de registro: vincular las sesiones a material de claves de confianza ya existente, como certificados mTLS o claves de seguridad de hardware, en lugar de crear una clave nueva al iniciar sesión.
- Compatibilidad con más dispositivos: estudiar la incorporación de claves basadas en software para proteger dispositivos que no incluyen hardware de seguridad específico.