Chrome DBSC: cookies ligadas al hardware para detener el secuestro de cuentas

Google ha empezado el despliegue general de Chrome Device Bound Session Credentials (DBSC), una función de seguridad que ata criptográficamente las sesiones de navegador al hardware del equipo para evitar que cookies robadas permitan secuestros de cuentas.

DBSC no es un parche cualquiera: vincula las cookies de sesión a claves de hardware no exportables, generadas por elementos seguros como el Trusted Platform Module (TPM) en Windows o el Secure Enclave en macOS. Esa asociación significa que, aunque un atacante consiga extraer una cookie, no podrá reutilizarla desde otro dispositivo porque no dispone de la clave privada almacenada en el chip del equipo original.

Google explica que la función estuvo en beta desde abril y ahora se activa para todos los clientes de Google Workspace, suscriptores individuales y cuentas personales, habilitada por defecto y sin opción para que los administradores la desactiven, lo que subraya la intención de Google de elevar el nivel de protección contra este vector de ataque. Puede leer el anuncio oficial aquí: Prevent account takeovers with DBSC — Workspace Updates.

El enfoque de DBSC cambia la táctica de muchas defensas: en lugar de depender solo de detección post‑compromiso, busca hacer inútil la mercancía robada. Esto ataca directamente abusos que se han observado en la práctica, como la explotación de endpoints OAuth no documentados o la capacidad de info‑stealers para restaurar cookies expiradas, técnicas que han sido aprovechadas por familias de malware y operaciones especializadas.

Aunque es una mejora significativa, DBSC no es una bala de plata. Protege contra la reutilización remota de cookies exfiltradas, pero no impide que un atacante que controle el propio dispositivo actúe durante una sesión en vivo, ni sustituye la necesidad de controlar el malware endémico en endpoints, la protección contra phishing o políticas de acceso robustas. Por eso sigue siendo importante combinar DBSC con otras medidas como navegación segura, detección y respuesta en endpoints y autenticación resistente a phishing.

Para entender el fundamento técnico conviene recordar que DBSC se apoya en mecanismos de autenticación de plataforma: claves generadas por hardware y APIs del navegador que enlazan las credenciales de sesión al dispositivo. Estos principios están relacionados con tecnologías y estándares como WebAuthn y el uso de autenticadores protegidos por hardware; más información técnica puede consultarse en la especificación oficial: W3C WebAuthn, y en la documentación sobre módulos TPM de plataforma: Trusted Platform Module (TPM) — Microsoft Docs.

Desde la perspectiva de TI y de las organizaciones, la obligatoriedad de la función para clientes Workspace reduce el riesgo operativo pero también obliga a validar compatibilidad: equipos antiguos sin hardware seguro o navegadores no actualizados podrían comportarse de forma diferente. Es recomendable testar la implementación en entornos controlados antes de depender de DBSC como único amortiguador frente a incidentes.

Si administras seguridad en una organización o eres usuario preocupado por la protección de tus credenciales, algunas acciones prácticas son claras: mantén Chrome y sistemas operativos actualizados, verifica que los equipos cuenten con TPM o equivalentes, mantén soluciones de EDR/antimalware activas, habilita modos de navegación segura y fomenta mecanismos de autenticación resistentes al phishing (por ejemplo, passkeys/WebAuthn). También es buena práctica auditar sesiones activas y aprender a revocar accesos sospechosos desde el panel de Google.

En resumen, DBSC representa un avance técnico relevante porque eleva la barrera para los atacantes que lucran con cookies robadas, pero su eficacia máxima llega cuando se integra en una estrategia de defensa en profundidad: protección de endpoints, autenticación sólida y políticas organizativas coordinadas seguirán siendo imprescindibles para reducir el riesgo real de toma de cuentas.