Adiós a las cookies robadas ahora la autenticación queda ligada al dispositivo en Chrome

Hace años que los atacantes buscan formas sencillas y lucrativas de acceder a cuentas en línea: en lugar de romper contraseñas, roban lo que ya concede acceso temporal a un servicio: las cookies de sesión. Estos tokens, si duran lo suficiente, permiten a un intruso entrar en una cuenta sin necesidad de conocer la contraseña, y con frecuencia acaban empaquetados y revendidos en el mercado del delito cibernético. Para contrarrestar esta amenaza Google ha decidido atar esas sesiones a la propia máquina del usuario mediante una tecnología que ahora comienza a llegar a todos los usuarios de Chrome en Windows.

Device Bound Session Credentials (DBSC) es la respuesta de Google al problema de la «exfiltración de sesiones». En términos sencillos, en lugar de que la mera posesión de una cookie baste para entrar en una cuenta, Chrome puede exigir que el navegador demuestre criptográficamente que la cookie está siendo usada desde el mismo dispositivo que la generó. De este modo, si un malware consigue copiar la cookie y la envía a un servidor controlado por el atacante, esa cookie pierde valor porque no puede probar que proviene del equipo legítimo.

La técnica se apoya en módulos de seguridad presentes en el hardware: en Windows se aprovecha el Trusted Platform Module (TPM) y, en ordenadores Apple, el equivalente sería el Secure Enclave. Estos entornos permiten crear claves criptográficas privadas que no se pueden exportar fuera del dispositivo. Cuando el servidor necesita emitir o renovar un token de sesión, solicita a Chrome una prueba de posesión de esa clave privada. Chrome firma o participa en un protocolo que demuestra esa posesión sin revelar la clave en sí. El resultado es que las cookies se convierten en efímeras y ligadas a la máquina, no transferibles.

Google empezó a probar DBSC en versión beta abierta y ahora anuncia que la funcionalidad está disponible para todos los usuarios de Windows que actualicen a Chrome 146; el soporte para macOS llegará en una versión posterior del navegador. La compañía explica que, cuando el dispositivo no dispone de almacenamiento seguro de claves, DBSC no rompe el flujo de autenticación: simplemente vuelve al comportamiento tradicional para no dejar al usuario sin acceso. Esta transición suave es importante para no causar fricciones en equipos más antiguos o en entornos virtualizados donde no exista TPM físico.

Los impulsores de la función afirman haber observado una reducción notable en los intentos de robo de sesión desde las primeras pruebas, lo que sugiere que atar las sesiones al hardware sí puede degradar significativamente la rentabilidad del negocio para los operadores de «stealers» —familias de malware que extraen datos del sistema—. Si quieres entender cómo funcionan estos programas maliciosos y por qué son tan peligrosos, hay análisis técnicos accesibles por ejemplo en el blog de Malwarebytes sobre familias como Vidar y otras amenazas similares: Malwarebytes Labs.

DBSC no surge en un vacío: forma parte de una tendencia mayor hacia la autenticación «ligada al dispositivo» y el uso generalizado de elementos seguros de hardware. En ese ecosistema hay vínculos con estándares y tecnologías como WebAuthn y la FIDO Alliance, que buscan reducir la dependencia de contraseñas y llevar la verificación criptográfica a la autenticación cotidiana. Si te interesa profundizar sobre los estándares de autenticación moderna, la FIDO Alliance ofrece documentación accesible: fidoalliance.org.

Privacidad y límites. Google ha diseñado la arquitectura con criterios claros de privacidad: la verificación se realiza con una clave por sesión y, según la compañía, no implica enviar identificadores del dispositivo ni datos de atestación que permitan correlacionar actividad entre sitios. En otras palabras, la intención es mejorar la seguridad sin convertir las claves de sesión en un mecanismo de seguimiento. Esto es importante porque una solución que protegiera sesiones pero permitiera perfilar usuarios habría sido inaceptable.

No obstante, existen limitaciones prácticas que conviene tener en cuenta. Si un atacante consigue control completo del dispositivo (por ejemplo, mediante un rootkit o un acceso físico prolongado), puede restaurar o manipular estados locales y potencialmente sortear mitigaciones. Asimismo, entornos virtualizados y máquinas sin TPM físico representan desafíos: el mecanismo simplemente se desactiva y vuelve al comportamiento tradicional para mantener la usabilidad. También hay cuestiones operativas para empresas: la gestión de dispositivos, la migración de usuarios entre máquinas, o políticas de recuperación de credenciales pueden requerir soluciones complementarias (por ejemplo, escrows de claves o procedimientos de restauración) que deben diseñarse con cuidado.

En el plano institucional, la llegada de DBSC supone un punto interesante para equipos de seguridad y administradores: puede reducir el riesgo asociado a cookies robadas, pero no sustituye a otras defensas. La combinación de múltiples capas —actualizaciones frecuentes del navegador, autenticación multifactor (MFA), protección endpoint y formación al usuario sobre el peligro del malware— sigue siendo la estrategia más robusta. Para entender mejor el papel del TPM en Windows y cómo se integra en la cadena de confianza, Microsoft ofrece documentación técnica accesible aquí: Microsoft Learn – TPM. Apple, por su parte, documenta su Secure Enclave en sus páginas de seguridad del desarrollador: Secure Enclave – Apple.

Otro aspecto positivo es que Google trabajó con Microsoft para que el diseño sea compatible con un objetivo más amplio: convertir la técnica en algo interoperable y, en la medida de lo posible, convertible en un estándar abierto que otros navegadores y servicios puedan adoptar. Ese enfoque colaborativo aumenta las probabilidades de que la protección no quede limitada a un solo ecosistema y, con suerte, eleve la seguridad del conjunto de la web.

Para el usuario medio el consejo es directo: mantener Chrome actualizado (la protección llega con versiones recientes), usar MFA en todas las cuentas que lo permitan y considerar llaves físicas de seguridad cuando sea posible. En entornos corporativos, los equipos de TI deberían evaluar cómo DBSC encaja en sus políticas de gestión de dispositivos y en sus flujos de recuperación de cuentas. La meta no es sustituir las buenas prácticas, sino reducir una ventana de exposición que hasta ahora era especialmente rentable para los atacantes.

Si quieres leer las notas oficiales de las actualizaciones de Chrome o seguir la información de seguridad publicada por Google, las páginas de anuncios de Chrome y el blog de seguridad de Google son buenos puntos de partida: Chrome Releases y Google Security Blog. La combinación de estas piezas —documentación del navegador, información sobre el hardware de seguridad y análisis de amenazas— ayuda a entender por qué atar sesiones al dispositivo puede suponer una mejora real en la lucha contra el robo de sesiones.