- Google habilita de forma estable DBSC en Chrome 146 para Windows para combatir el robo de cookies de sesión.
- Las sesiones se vinculan criptográficamente al hardware del dispositivo mediante TPM, inutilizando las cookies robadas en otros equipos.
- La tecnología forma parte de un estándar web abierto impulsado por Google y Microsoft, con futura llegada a macOS y otros entornos.
- El sistema refuerza la seguridad y limita el rastreo entre sitios, alineándose con las exigencias de privacidad en España y la Unión Europea.
Google ha empezado a desplegar en Chrome 146 para Windows una nueva capa de protección diseñada específicamente para cortar uno de los ataques más rentables para los ciberdelincuentes: el robo y reutilización de cookies de sesión. Esta función se llama Device Bound Session Credentials, o simplemente DBSC, y a partir de ahora pasa a estar disponible de forma estable para todos los usuarios del navegador en equipos con Windows compatibles.
Con este movimiento, la compañía quiere ponerle las cosas bastante más difíciles al malware infostealer, que en los últimos años se ha dedicado a vaciar navegadores, robar cookies de autenticación y vender accesos a cuentas ya abiertas en foros clandestinos. La idea de DBSC es sencilla de entender: que las sesiones que se generan en Chrome queden unidas al dispositivo donde se inician, de forma que una cookie robada deje de servir en cuanto sale del ordenador original.
Qué es DBSC y qué problema viene a resolver en Chrome 146
Las llamadas Device Bound Session Credentials son un sistema mediante el cual cada sesión de usuario queda asociada criptográficamente al equipo desde el que se ha iniciado. En lugar de fiarlo todo a las cookies tradicionales, que pueden copiarse y cargarse en otro sistema sin demasiada complicación, DBSC añade un requisito extra: el navegador tiene que demostrar al servidor que todavía controla una clave privada generada y custodiada por el propio hardware.
El problema de fondo es conocido: cuando un ordenador se infecta con malware especializado, este es capaz de extraer las cookies de sesión almacenadas por el navegador y enviarlas al atacante. Esas cookies contienen tokens válidos que permiten entrar en correo, redes sociales, banca online o servicios corporativos sin introducir contraseña ni pasar por la autenticación en dos pasos. En la práctica, el ciberdelincuente se cuela como si fuera el usuario legítimo.
En España y en el resto de Europa esto no es un tema menor, sobre todo por el auge del teletrabajo y el acceso remoto a herramientas de empresa y servicios públicos. Los infostealers llevan tiempo apuntando a este tipo de entornos, tanto en ordenadores domésticos como en equipos profesionales, vendiendo luego las sesiones robadas al mejor postor. Para muchas organizaciones, detectar que alguien se ha conectado aprovechando una cookie robada puede ser muy complicado.
Hasta ahora, la estrategia general consistía en reaccionar después del robo: intentar detectar usos sospechosos, cerrar sesiones activas y forzar nuevos inicios de sesión. DBSC cambia el enfoque por completo, porque hace que esas cookies exfiltradas pierdan el valor nada más salir del dispositivo donde se crearon. Es decir, el atacante puede seguir robándolas, pero cuando las cargue en otro ordenador no le servirán de puerta de entrada.
Cómo funciona la vinculación de las sesiones al dispositivo
Para conseguir este efecto, Chrome se apoya en los módulos de seguridad incluidos en el propio hardware del ordenador. En el caso de Windows, el navegador utiliza el TPM (Trusted Platform Module), un chip pensado para generar y proteger claves criptográficas de manera que no puedan copiarse ni salir del equipo. En macOS está previsto usar el Secure Enclave, aunque ese despliegue llegará más adelante.
El mecanismo es el siguiente: cuando un sitio web compatible establece una nueva sesión, Chrome le pide al chip de seguridad que genere o utilice una clave privada asociada a esa sesión. El navegador puede compartir con el servidor únicamente la clave pública correspondiente, mientras que la privada queda encadenada al TPM y es inaccesible desde el exterior, incluso para otros programas del sistema.
A partir de ese momento, la renovación de las cookies de sesión y la emisión de credenciales de corta duración depende de que Chrome sea capaz de probar criptográficamente que sigue teniendo la clave privada. Cada vez que el servidor lo solicita, el navegador firma ciertos datos y el servicio verifica la firma utilizando la clave pública registrada al inicio. Si la prueba se supera, la sesión continúa con normalidad.
Si un atacante ha conseguido copiar los archivos donde se guardan las cookies y trata de utilizarlos en otro ordenador, se encuentra con un problema insalvable: ese segundo equipo no tiene acceso a la clave privada generada por el TPM original. El servidor detecta que falta esa pieza y se niega a renovar o prolongar la sesión, por lo que las cookies robadas pasan a ser, en la práctica, credenciales inútiles fuera del dispositivo legítimo.
Además, Google afirma haber diseñado el sistema para que no se filtren identificadores permanentes del dispositivo hacia los servidores de los sitios web. La comunicación se limita a los datos estrictamente necesarios para validar la sesión, sin exponer número de serie del hardware ni otros elementos que pudieran usarse para construir una huella digital duradera del equipo.
Despliegue en Chrome 146 para Windows y requisitos técnicos
La activación de DBSC llega ahora de forma estable a Chrome 146 en sistemas Windows. Tras una fase de pruebas inicial en entornos empresariales con cuentas de Google Workspace, la función se abre al conjunto de usuarios, siempre que su equipo cumpla los requisitos mínimos. La prioridad de Google ha sido aprovechar la amplia presencia del TPM en ordenadores con Windows 10 y Windows 11.
Desde el punto de vista del usuario, no hace falta tocar ajustes avanzados: la protección se integra directamente dentro del motor de autenticación del navegador. Lo único imprescindible es tener Chrome actualizado a la versión 146 o superior y contar con un TPM operativo. Para comprobarlo, basta con ir al menú de tres puntos en la esquina superior derecha, entrar en «Ayuda» y después en «Información de Google Chrome», donde el propio navegador revisa e instala actualizaciones.
En la mayoría de equipos modernos el TPM viene ya activado de fábrica, porque también se utiliza para funciones como BitLocker o Windows Hello. Si el módulo está presente y funcional, DBSC se pone en marcha automáticamente cuando los sitios que visitas son compatibles con esta tecnología. Los usuarios de Windows en España y Europa, tanto en hogares como en empresas, se benefician de este despliegue global sin que haya diferencias entre regiones.
Conviene recordar, eso sí, que DBSC no actúa como un antivirus ni sustituye a otras capas de seguridad. La máquina puede seguir infectándose con malware si el usuario descarga archivos sospechosos o instala extensiones dudosas, pero al menos las cookies robadas dejan de ser un premio tan jugoso. Es un cambio relevante en el equilibrio de fuerzas entre atacantes y defensores.
Para quienes sospechen que sus sesiones han podido verse comprometidas en algún momento, sigue siendo recomendable cerrar todas las sesiones activas en cuentas sensibles —banca, correo, redes sociales— y cambiar las contraseñas. DBSC no repara ataques pasados, pero sí reduce la eficacia de los futuros intentos de robo de sesiones a través de Chrome.
Efecto sobre el robo de cookies, infostealers y seguridad en Europa
Una de las consecuencias más directas de DBSC es que ataca el modelo de negocio de los llamados infostealers, esos programas que se dedican a recopilar contraseñas, formularios y cookies de sesión de los navegadores. Hasta ahora, muchas de estas familias de malware obtenían beneficios vendiendo sesiones activas que daban acceso inmediato a cuentas concretas, a menudo de servicios financieros o corporativos.
Con las credenciales vinculadas al dispositivo, incluso si el infostealer consigue volcar los archivos internos de Chrome, esas cookies no pueden reutilizarse en otro equipo, que es justamente lo que hacen los atacantes para explotar o revender el acceso. Sin la clave privada generada por el TPM, la cookie robada se convierte en un souvenir inútil para el ciberdelincuente, que pierde la posibilidad de entrar como si fuera el usuario original.
Este cambio también afecta a los ataques que evitan la autenticación en dos pasos. En muchos incidentes recientes, los atacantes no se molestaban en robar contraseñas ni códigos SMS: les bastaba con capturar la cookie de sesión de un usuario que ya había pasado esos controles. Incluso cambiar la contraseña no siempre expulsaba al intruso de inmediato, porque la sesión se mantenía válida durante un tiempo. Con DBSC, esa ventana de oportunidad se acorta drásticamente.
En el contexto europeo, donde España y otros países de la UE han visto crecer los incidentes relacionados con el robo de credenciales, esta medida encaja con la necesidad de elevar el nivel de protección sin complicar en exceso la vida del usuario. Banca online, portales de administración electrónica, plataformas sanitarias o herramientas de teletrabajo se ven beneficiadas si sus proveedores activan el soporte para DBSC en sus servidores.
Es importante matizar que la tecnología no impide la infección ni evita que el malware robe otros tipos de datos, pero reduce de forma notable el valor de las sesiones exfiltradas. Para muchas empresas europeas, acostumbradas a lidiar con campañas de robo de credenciales dirigidas a empleados que trabajan desde casa, esta capa extra puede marcar la diferencia en incidentes que hasta ahora resultaban difíciles de detectar y contener.
Privacidad, estándar abierto y límites al rastreo entre sitios
Más allá de la seguridad, Google ha insistido en que DBSC se ha diseñado teniendo muy presentes las implicaciones en materia de privacidad y protección de datos, aspectos especialmente sensibles bajo el paraguas del Reglamento General de Protección de Datos (RGPD) y otras normas europeas. Para evitar que el mecanismo se convierta en un identificador permanente del dispositivo, cada sesión utiliza su propio conjunto de claves.
Esto significa que los sitios web no pueden utilizar DBSC para rastrear al usuario de una página a otra ni para construir un historial completo de su actividad en Internet. Las claves asociadas a un servicio no sirven para identificar al navegador frente a otros servicios distintos, lo que limita la capacidad de crear huellas digitales detalladas basadas en esta tecnología.
En la práctica, el sistema se ajusta a los principios de minimización de datos que exige la normativa europea: los servidores reciben solo la información estrictamente necesaria para verificar que la sesión sigue vinculada al mismo dispositivo, sin detalles adicionales sobre el hardware ni datos personales. Esto permite a bancos, administraciones públicas y proveedores de servicios críticos reforzar la seguridad sin aumentar el volumen de información sensible que procesan.
Otro aspecto relevante es que DBSC forma parte de un estándar web abierto en el W3C, el organismo que coordina muchas de las especificaciones de Internet. En su definición han participado no solo Google, sino también otras empresas del sector como Microsoft u Okta, lo que abre la puerta a que la idea de las sesiones ligadas al dispositivo se extienda a otros navegadores y plataformas más allá de Chrome en Windows.
Durante las fases de pruebas, Google asegura haber observado una reducción notable de los intentos de robo de sesión exitosos en los entornos corporativos donde se activó DBSC. De cara al futuro, la compañía planea ampliar su uso para proteger también flujos de inicio de sesión único (SSO) en empresas y explorar soluciones de software para dispositivos más antiguos que no cuentan con módulos de seguridad dedicados, algo relevante para parques informáticos envejecidos que aún se ven en algunas organizaciones europeas.
Qué deben hacer las webs y qué puede hacer el usuario
Para que DBSC sea realmente efectivo, no basta con que Chrome implemente el protocolo: las propias páginas web tienen que activar el soporte en sus sistemas de autenticación. Plataformas como redes sociales, servicios de correo, entidades bancarias o aplicaciones empresariales deberán adaptar su backend para aprovechar las claves vinculadas al dispositivo que ofrece el navegador.
Google ha publicado una guía técnica orientada a desarrolladores donde se detallan los pasos para integrar DBSC. La idea es que los proveedores puedan seguir usando cookies como mecanismo principal de sesión, pero añadiendo una capa criptográfica que compruebe si esa cookie sigue asociada al mismo dispositivo desde el que se inició. De este modo, pueden reforzar la seguridad sin necesidad de rediseñar por completo sus procesos de inicio de sesión.
Por parte del usuario, la responsabilidad es mucho más sencilla: mantener Chrome al día y, en la medida de lo posible, asegurarse de que el sistema operativo y el hardware cumplen los requisitos mínimos. En Windows, contar con un TPM activo se ha convertido prácticamente en el estándar, sobre todo desde la llegada de Windows 11, por lo que gran parte de los usuarios no tendrá que hacer nada adicional.
Si ya se ha sufrido un robo de cookies en el pasado, las recomendaciones generales siguen siendo válidas: cerrar las sesiones abiertas en los servicios más sensibles, cambiar las contraseñas y revisar la actividad reciente en las cuentas. A partir de la versión 146, DBSC ayuda a evitar que episodios similares vuelvan a producirse de la misma forma, pero no puede deshacer una filtración previa ni cancelar accesos que el atacante ya haya aprovechado.
En España, donde el acceso frecuente a banca online, plataformas de la Administración y servicios educativos digitales es cada vez más habitual, esta capa extra puede suponer un salvavidas silencioso para muchos usuarios que nunca llegan a ser conscientes de los intentos de robo que se producen en segundo plano. En las empresas con trabajadores en remoto o con dispositivos portátiles que se conectan desde distintos lugares, la adopción de DBSC por parte de los servicios que utilizan puede reforzar de forma significativa la protección de los recursos internos.
En conjunto, la activación de DBSC en Chrome 146 para Windows representa un cambio de enfoque en la forma de proteger las sesiones online: las cookies dejan de poder viajar libremente de un dispositivo a otro y pasan a depender de una clave atada al hardware, lo que pone cuesta arriba el negocio del robo de identidades basado en malware. Aunque aún queda camino por recorrer en cuanto a adopción por parte de los sitios web y expansión a otros sistemas operativos como macOS, los usuarios de Windows en España y el resto de Europa ya cuentan con una herramienta adicional que endurece notablemente el secuestro de cuentas sin sacrificar la privacidad.
