--- service: "Publicasta" schema_version: "1.0" article_id: 319 title: "Chrome vincula sesiones al dispositivo: buena noticia contra el robo de cuentas" language: "es" default_language: "en" canonical_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=es" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=es" api_url: "https://publicasta.com/api/public/v1/channels/good_tech_news/articles/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=es" channel_url: "https://publicasta.com/api/public/v1/channels/good_tech_news" channel_articles: "https://publicasta.com/api/public/v1/channels/good_tech_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-08-13T17:14:41+00:00" updated_at: "2026-08-13T17:14:41+00:00" translations: - language: "ar" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=ar" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=ar" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=ar" - language: "de" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=de" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=de" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=de" - language: "en" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=en" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=en" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=en" - language: "es" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=es" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=es" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=es" - language: "fr" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=fr" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=fr" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=pl" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=pl" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=ru" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=ru" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=zh" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=zh" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=zh" --- # Chrome vincula sesiones al dispositivo: buena noticia contra el robo de cuentas > Device-Bound Session Credentials no elimina el robo de cookies, pero puede hacer que las sesiones robadas sean mucho menos portables. La autenticación de dos factores y las passkeys hicieron que robar una contraseña fuese menos decisivo. Los atacantes se movieron hacia lo que ocurre después del inicio de sesión: la sesión del navegador. Una cookie de sesión robada puede hacer que un delincuente parezca ya autenticado, incluso si la cuenta usa protección fuerte. Por eso la llegada de Device-Bound Session Credentials, DBSC, a Chrome es una buena noticia tecnológica: no promete magia, pero ataca una debilidad real en la capa de protocolo, navegador y dispositivo. ![Sesión web vinculada a un chip de seguridad del portátil y a un reto del servidor](https://publicasta.com/storage/projects/16/pages/319/2026/08/5d588949-ee98-439d-a49c-a0c84010b832.webp) El contexto reciente viene de Ars Technica, del borrador público del W3C, del explainer de WICG y de la documentación de Google Workspace sobre session binding contra el robo de cookies. La idea central es sencilla: cuando un sitio compatible crea una sesión, el navegador genera una clave criptográfica que debe quedarse en el dispositivo original. Más tarde, el servidor puede pedir al navegador una prueba de posesión. Si un infostealer copió la cookie a otro equipo, la cookie sola ya no debería bastar. ## El hueco que intenta cerrar Una cookie de sesión existe por comodidad. Después de entrar, el sitio no pide contraseña y segundo factor en cada página. El navegador envía una cookie y el servidor la trata como señal de la misma sesión. El problema es que ese modelo se parece a un bearer token: quien lo lleva puede usarlo. DBSC añade una condición: para refrescar o validar ciertos cookies, el navegador debe demostrar que conserva la clave privada vinculada a esa sesión y a ese dispositivo. Esto importa porque la economía del ataque cambió. El phishing de contraseñas sigue existiendo, pero passkeys, llaves de seguridad y MFA fuerte lo hacen menos fiable contra cuentas valiosas. El robo de sesión evita esa mejora. Malware, extensiones maliciosas, kits adversary-in-the-middle y logs mal protegidos pueden convertir un navegador ya autenticado en una fuente de tokens. DBSC reduce el valor de copiar esos tokens fuera del dispositivo. ## Cómo funciona sin misterio El servidor indica que debe registrarse una sesión segura. El navegador crea un par de claves para esa sesión. La clave privada se guarda, cuando es posible, en un componente protegido del dispositivo. La documentación pública habla de TPM en Windows; los análisis técnicos mencionan Secure Enclave en plataformas Apple. El detalle puede variar por navegador, pero el objetivo es el mismo: la clave privada no debe ser un archivo exportable. Durante el registro y en refrescos posteriores, el navegador firma un reto. El servidor no necesita recibir una identidad permanente del hardware. El texto de WICG dice que la cadena de certificado del TPM no se envía al servidor porque permitiría una huella muy precisa. El servidor solo debería comprobar que ese navegador conserva la clave asociada a la sesión. No es lo mismo que una passkey. La passkey protege el acto de iniciar sesión. DBSC protege la continuidad de la sesión ya creada. Uno cuida la puerta; el otro reduce el valor de una credencial robada después de pasar la puerta. ## Por qué es una mejora concreta Muchas medidas de seguridad dependen de que el usuario acierte en el peor momento: no pulsar el enlace, notar el dominio falso, rechazar una notificación sospechosa. DBSC es interesante porque la comprobación principal es automática. Si el atacante solo tiene la cookie robada, le falta la clave privada con la que el navegador legítimo responde al reto. Para empresas, el efecto puede ser grande. Una sesión robada en correo corporativo, CRM, consola cloud, panel de administración o sistema financiero puede abrir documentos, clientes y configuraciones internas. Google Workspace presenta session binding como control contra cookie theft: la sesión debe servir en el dispositivo gestionado y ser mucho menos útil al copiarse. Si el patrón se extiende, el negocio de los infostealers pierde parte de su rentabilidad. ## Límites que no conviene ocultar DBSC no neutraliza malware que sigue ejecutándose en el mismo dispositivo. Ese malware puede operar a través del navegador real, esperar tokens frescos, abusar de extensiones o usar el entorno protegido como oráculo de firma. El propio explainer de WICG trata el acceso persistente al user agent comprometido como un límite. La promesa fuerte es más estrecha: un acceso temporal no debería convertirse automáticamente en una sesión remota duradera después de limpiar el dispositivo. Tampoco arregla recuperación de cuenta débil, servidores comprometidos, soporte engañado por ingeniería social, extensiones peligrosas o políticas de sesión demasiado largas. El sitio debe implementar el protocolo, el navegador debe soportarlo y la empresa debe tener procedimientos claros para pérdida o cambio de dispositivo. ## Privacidad y huella digital La preocupación por fingerprinting es legítima. Si un navegador expusiera una identidad estable de TPM o Secure Enclave, sería un desastre de privacidad. Los borradores de DBSC intentan evitarlo: claves separadas por sesión, imposibilidad de vincular claves diferentes al mismo dispositivo y no envío de la cadena TPM al servidor. También limitan los refrescos de fondo mediante contexto de solicitud, acceso a cookies y estado activo del sitio. Esa parte merece vigilancia continua. La buena noticia no es “confiemos sin preguntar”, sino que el problema está reconocido en el diseño público. Las condiciones razonables son claras: claves por sitio o sesión, nada de identidad hardware estable, controles empresariales transparentes, recuperación comprensible y revisión independiente. ## Qué hacer ahora Ars informó de soporte en nuevas versiones de Chrome para Windows y macOS, con disponibilidad todavía limitada. WICG y W3C muestran que el trabajo sigue en estandarización, así que nadie debe asumir protección universal. Administradores e identity teams deberían vigilar la documentación de Google Workspace, preguntar a proveedores por session binding, revisar logs y preparar playbooks para incidentes de cookie theft. Los usuarios no necesitan buscar un botón mágico. Deben mantener el navegador actualizado, usar passkeys o MFA fuerte, eliminar extensiones dudosas y tomar en serio la seguridad del dispositivo. Si DBSC se despliega bien, lo mejor será aburrido: menos cookies robadas que funcionan fuera del equipo, menos bucles de inicio de sesión y más fallos por defecto para el atacante. ## Conclusión DBSC es alentador porque protege una fase que durante años fue demasiado parecida a “quien tiene la cookie tiene la sesión”. No acaba con el robo de cuentas, pero hace menos fiable una ruta muy práctica: robar una sesión y repetirla en otra máquina. En seguridad, convertir un ataque barato en uno menos portable y más detectable ya es un avance real. ## Fuentes Ars Technica, Dan Goodin, 11 de agosto de 2026; W3C Editor's Draft de Device Bound Session Credentials; WICG DBSC explainer y repositorio; ayuda de Google Workspace sobre session binding; análisis de Scott Helme; explicación de Corbado sobre DBSC, passkeys y seguridad de sesiones; Hacker News item 49268757 como señal de debate técnico sobre TPM, Secure Enclave, passkeys y fingerprinting.