--- url: 'https://www.corbado.com/es/blog/device-bound-session-credentials-dbsc' title: 'Explicación de las Device Bound Session Credentials (DBSC)' description: 'Descubra cómo las Device Bound Session Credentials (DBSC) evitan el secuestro de sesiones y el robo de cookies. Conozca su compatibilidad y la seguridad empresarial.' lang: 'es' author: 'Vincent Delitz' date: '2026-06-15T13:56:39.261Z' lastModified: '2026-06-16T06:03:18.146Z' keywords: 'Device Bound Session Credentials, DBSC, prevención de secuestro de sesiones, protección contra robo de cookies, vinculación de sesiones TPM, robo de cookies' category: 'Authentication' --- # Explicación de las Device Bound Session Credentials (DBSC) **Estado de compatibilidad en navegadores** > **Novedades (abril de 2026):** Chrome 146 lanza > [DBSC con disponibilidad general en Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), > sacando la función de su fase de prueba de origen (Origin Trial). La compatibilidad con > macOS (utilizando [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) llegará en una próxima > versión de Chrome. Google también anunció una hoja de ruta pública para la identidad > federada (vinculaciones [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) de > [origen cruzado](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn)), el registro avanzado (mTLS / > claves de hardware) y claves basadas en software para dispositivos sin hardware seguro. | Navegador | Windows | macOS | Linux | Android | iOS | Estado | | ----------- | ----------------------- | -------------------------------- | --------------- | --------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 Próximamente (Secure Enclave) | ❌ | ❌ | ❌ | [GA en Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (abril de 2026), macOS en una próxima versión | | **Edge** | ⏸️ Prueba finalizada | ❌ | ❌ | ❌ | ❌ | La prueba de origen finalizó en oct. de 2025, sin disponibilidad general anunciada | | **Safari** | N/A | 🔄 Evaluando | N/A | N/A | 🔄 Evaluando | WebKit en discusión, sin implementación anunciada | | **Firefox** | 🔄 Monitoreando | 🔄 Monitoreando | 🔄 Monitoreando | 🔄 Monitoreando | 🔄 Monitoreando | Evaluando, sin compromiso de implementación | **Leyenda:** ✅ Disponibilidad general | 🚧 Anunciado / en desarrollo | ⏸️ Prueba finalizada | 🔄 Evaluando/monitoreando | ❌ Aún no disponible **Nota:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) tiene disponibilidad general (GA) en Windows con TPM a partir de Chrome 146 (abril de 2026). La compatibilidad con macOS a través de [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) se implementará a continuación. La hoja de ruta indicada por Google también incluye claves basadas en software para extender la protección a dispositivos sin hardware seguro dedicado. **Principales ventajas: DBSC vs. modelo actual** | **Característica** | **Modelo de cookies actual** | **Modelo DBSC** | | ------------------------- | ----------------------------------- | --------------------------------------------------------- | | **Tipo de token** | Portador (posesión = acceso) | Vinculado (posesión + clave = acceso) | | **Consecuencia de robo** | Toma de control total de la cuenta | Token inútil (no se puede actualizar) | | **Duración de la sesión** | Corta (por seguridad) | Larga / infinita (seguro por diseño) | | **Fricción del usuario** | Alta (inicios de sesión frecuentes) | Baja (seguridad invisible) | | **Evasión de MFA** | Vulnerable (pasar la cookie) | Resistente (se requiere dispositivo) | | **Revocación** | Lenta (esperar a que caduque) | Casi en tiempo real (falla en la siguiente actualización) | ## Key Facts - **DBSC** vincula las sesiones web a una clave criptográfica alojada en el dispositivo, lo que hace que las cookies robadas sean inútiles porque no se pueden actualizar desde otro dispositivo. - El navegador almacena una clave privada no exportable en un **TPM**, firmando los desafíos del servidor cada 5 minutos para demostrar la posesión del dispositivo sin interacción del usuario. - A diferencia del **Token Binding** (vinculación de tokens), que fracasó debido a la complejidad de la infraestructura en la capa TLS, DBSC opera en la capa de aplicación HTTP y funciona de manera transparente con los equilibradores de carga y las CDN existentes. - **Chrome 146 incluye DBSC con disponibilidad general en Windows (abril de 2026)**, y la compatibilidad con Secure Enclave de macOS llegará en una próxima versión. La hoja de ruta publicada por Google también abarca la identidad federada (vinculaciones SSO de origen cruzado), el registro avanzado (mTLS / claves de hardware) y las claves basadas en software para dispositivos sin hardware seguro. Safari y Firefox aún lo están evaluando; la prueba de origen de Edge finalizó en octubre de 2025 sin anunciar disponibilidad general. ## 1. Introducción: Device Bound Session Credentials (DBSC) La arquitectura de la World Wide [Web](https://www.corbado.com/es/blog/proveedores-passkeys) se fundó sobre un principio de falta de estado. Cuando el HTTP se diseñó por primera vez, no retenía información sobre los usuarios entre las solicitudes. Para resolver esto, se inventó la "cookie": un pequeño fragmento de datos enviado desde un sitio [web](https://www.corbado.com/es/blog/proveedores-passkeys) y almacenado en la computadora del usuario, para ser enviado de vuelta al sitio [web](https://www.corbado.com/es/blog/proveedores-passkeys) en cada solicitud posterior. Durante décadas, este mecanismo ha servido como base para la gestión de sesiones. Cuando un usuario inicia sesión, el servidor valida sus credenciales y emite una cookie. Esta cookie actúa como un "token de portador" (bearer token). En el mundo físico, un instrumento al portador es un documento que otorga al titular los derechos o activos que representa; si tiene el bono, es dueño del bono. De manera similar, en el mundo digital de HTTP, si tiene la cookie, es el usuario. Esta capacidad de portador es simultáneamente la mayor utilidad de la web y su vulnerabilidad más profunda. La [seguridad](https://www.corbado.com/es/blog/contrasenas-complejas-descifradas-pronto) de toda la sesión, y por extensión, la identidad, los datos y los activos financieros del usuario, descansa por completo en el secreto de esa cadena de cookies. Si un actor malintencionado puede copiar esa cadena, puede hacerse pasar por el usuario desde cualquier dispositivo, en cualquier parte del mundo, eludiendo por completo las comprobaciones de [autenticación](https://www.corbado.com/es/glossary/jwks) iniciales. Esta vulnerabilidad específica ha dado lugar a una economía sumergida a escala industrial de "robo de cookies" y "secuestro de sesiones". A medida que la industria refuerza con éxito la "puerta principal" de la [autenticación](https://www.corbado.com/es/glossary/jwks) mediante la adopción de los estándares [FIDO](https://www.corbado.com/es/glossary/cda) (Fast Identity Online) y las [claves de acceso](https://www.corbado.com/es/glossary/cda) (passkeys), los atacantes están cambiando su enfoque hacia la "puerta trasera": la sesión activa. Hacer [phishing](https://www.corbado.com/glossary/phishing) de una contraseña es cada vez más difícil, pero robar una cookie de sesión sigue siendo peligrosamente efectivo. La respuesta de la industria a esta amenaza creciente es **Device Bound Session Credentials (DBSC)**. [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) representa un cambio de paradigma en la forma en que se mantienen las sesiones web. Propone alejarse de los simples tokens de portador hacia un modelo en el que la sesión está [vinculada criptográficamente al dispositivo](https://www.w3.org/TR/dbsc/). Con [Chrome 146 (abril de 2026) lanzando DBSC en disponibilidad general para Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), el estándar ha pasado de ser experimental a una capacidad de producción que los equipos web pueden implementar hoy mismo. Chrome utiliza los TPM en Windows y, a continuación, implementará la compatibilidad con [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) en macOS; la especificación en sí es independiente del almacenamiento de claves y solo requiere que sea "robusto frente a la amenaza descrita". Esto hace que las cookies robadas sean mucho menos valiosas. No se pueden actualizar desde otro dispositivo sin la clave vinculada. Este artículo proporciona un análisis exhaustivo de [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc), diseñado para arquitectos de [seguridad](https://www.corbado.com/es/blog/contrasenas-complejas-descifradas-pronto), gerentes de producto y desarrolladores. Explora la arquitectura técnica, las implicaciones comerciales de la "[seguridad](https://www.corbado.com/es/blog/contrasenas-complejas-descifradas-pronto) sin fricciones", la relación con estándares emergentes como Shared Signals (CAEP/RISC), y cómo las organizaciones pueden prepararse para este futuro utilizando plataformas como Corbado. **Preguntas clave que responde este artículo** 1. ¿Por qué la gestión de sesiones actual no logra prevenir las tomas de control de cuentas? 2. ¿En qué se diferencia DBSC de las cookies "Seguras" existentes y las banderas HttpOnly? 3. ¿Cómo funcionan juntas DBSC y las [claves de acceso](https://www.corbado.com/es/glossary/cda) para lograr una mayor resistencia al [phishing](https://www.corbado.com/glossary/phishing)? 4. ¿Qué pasó con el Token Binding y por qué DBSC tiene éxito donde este fracasó? 5. ¿Cuáles son las implicaciones comerciales y el ROI para los gerentes de producto? 6. ¿Qué navegadores y sistemas operativos son compatibles con DBSC hoy en día? 7. ¿Cómo pueden las organizaciones implementar DBSC sin crear nada desde cero? 8. ¿Cuál es la relación entre DBSC, DPoP y [OAuth 2.0](https://www.corbado.com/glossary/oauth2)? 9. ¿Cómo se integra DBSC con Shared Signals (CAEP/RISC) para una respuesta a amenazas en tiempo real? ## 2. Comprender los problemas y las soluciones fundamentales Para navegar por la complejidad de este nuevo estándar, primero debemos comprender los problemas fundamentales de la gestión de sesiones actual y cómo DBSC ofrece soluciones. Cada una de estas áreas representa una vulnerabilidad o limitación crítica que DBSC aborda. ### 2.1 El fracaso de la gestión de sesiones actual La falla fundamental de la gestión de sesiones actual es la "portabilidad" de la confianza. Cuando un servidor emite una cookie de sesión, esencialmente está emitiendo un pasaporte que funciona para cualquiera que lo posea. Aunque los navegadores han implementado defensas como [las banderas HttpOnly y Secure](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) (que evitan el acceso a JavaScript y aseguran la transmisión sobre HTTPS), estas defensas solo protegen contra vectores de extracción específicos como Cross-Site Scripting (XSS) o rastreo de red. No ofrecen ninguna protección contra [malware](https://www.corbado.com/glossary/malware) que se ejecuta en el dispositivo anfitrión. Los "Infostealers" son programas maliciosos diseñados específicamente para localizar el archivo de almacenamiento de cookies del navegador en el disco, descifrarlo (a menudo utilizando las propias credenciales de nivel de sistema operativo del usuario) y exfiltrar el contenido a un servidor de comando y control. Una vez que el atacante posee la cookie, puede realizar un [ataque de Pase de cookie (Pass-the-Cookie)](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html), inyectando el token robado en su propio navegador para secuestrar la sesión. El servidor, al ver una cookie válida, asume que la solicitud es legítima. ### 2.2 La ventaja criptográfica de DBSC sobre las cookies seguras tradicionales DBSC introduce un segundo factor de [autenticación](https://www.corbado.com/es/glossary/jwks) en el propio bucle de mantenimiento de la sesión. A diferencia de una cookie segura estándar, que es un secreto estático, una sesión DBSC consta de un token de portador de corta duración y una prueba de posesión criptográfica. El navegador genera un par de claves pública y privada que se almacenan de forma segura en el dispositivo. El servidor vincula la sesión a la clave pública. Periódicamente, el navegador debe demostrar que aún posee la clave privada firmando un desafío del servidor. La [especificación requiere un almacenamiento de claves](https://www.w3.org/TR/dbsc/) "robusto frente a la amenaza descrita". Chrome utiliza el TPM en Windows cuando está disponible. Si un atacante roba la cookie de un dispositivo diferente, no puede actualizarla porque no puede generar la firma criptográfica requerida. El aspecto de "portador" se reduce a una ventana de tiempo muy corta, mientras que el aspecto de "vinculación" proporciona una continuidad a largo plazo. ### 2.3 Sinergia entre las claves de acceso y DBSC Las [claves de acceso](https://www.corbado.com/es/glossary/cda) y DBSC son tecnologías complementarias que aseguran diferentes fases del ciclo de vida del usuario. Las claves de acceso (FIDO2) resuelven el problema de la _autenticación_, demostrando la identidad para iniciar una sesión [sin contraseñas](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) y, por lo tanto, eliminando el [phishing](https://www.corbado.com/glossary/phishing) de credenciales. DBSC aborda el problema de la fase _posterior a la autenticación_, haciendo que el secuestro de sesiones mediante el robo de cookies sea significativamente más difícil. La [Alianza FIDO enmarca a DBSC](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) como una tecnología complementaria que "eleva el nivel" contra el secuestro de sesiones. Juntos, reducen la superficie de ataque durante el ciclo de vida del inicio de sesión y la sesión, aunque DBSC no protege contra [malware](https://www.corbado.com/glossary/malware) con acceso continuo al dispositivo o ataques en tiempo real de intermediario en el navegador (browser-in-the-middle) en el mismo dispositivo. | Tecnologías | Phishing remoto | Relleno de credenciales | Robo de tokens | | ---------------------------------- | --------------- | ----------------------- | -------------- | | **Claves de acceso** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **Claves de acceso + DBSC / DPoP** | ✅ | ✅ | ✅ | **Cómo funcionan en conjunto las claves de acceso y DBSC** | **Aspecto** | **Claves de acceso** | **DBSC** | **Beneficio combinado** | | ---------------------------- | ------------------------------------------------------ | ----------------------------------------------------- | ----------------------------------------------------------- | | **Alcance** | Autenticación (inicio de sesión) | Gestión de sesiones | Protección integral | | **Amenaza mitigada** | Phishing de contraseñas, relleno de credenciales | Secuestro de sesiones remotas, robo de cookies | Nivel significativamente superior contra la toma de cuentas | | **Experiencia del usuario** | Inicio de sesión sin contraseñas | Protección de sesión transparente | Experiencia fluida y segura | | **Almacenamiento de claves** | Credenciales vinculadas al dispositivo o sincronizadas | Vinculado al dispositivo (HSM cuando esté disponible) | Autenticación flexible, vinculación rígida de sesiones | | **Implementación** | Reemplaza las contraseñas | Mejora las sesiones existentes | Mejoras progresivas en seguridad | ### 2.4 Aprendiendo del fracaso del Token Binding DBSC no es el primer intento de resolver este problema. El "Token Binding" fue un estándar anterior que intentaba vincular las cookies a la conexión subyacente TLS (Seguridad de la Capa de Transporte). Si bien era sólido desde el punto de vista criptográfico, el Token Binding no logró ser adoptado debido a su fuerte dependencia de la capa TLS. En la web moderna, las conexiones TLS a menudo terminan en equilibradores de carga, CDN o proxies inversos, mientras que la lógica de la aplicación reside en servidores ubicados detrás de ellos. Propagar la información de Token Binding a través de estas complejas capas de red demostró ser demasiado difícil. DBSC aprende de este fracaso [operando completamente en la capa de aplicación (HTTP)](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). No depende de la conexión de red subyacente, lo que lo hace compatible con los equilibradores de carga, proxies e infraestructura en la nube existentes. ### 2.5 Implicaciones comerciales y oportunidades de ROI Para los líderes de producto, DBSC ofrece una oportunidad para mejorar la seguridad y, al mismo tiempo, mejorar la experiencia del usuario (UX). Tradicionalmente, una alta seguridad significaba tiempos de espera de sesión cortos, lo que obligaba a los usuarios a iniciar sesión con frecuencia (fricción). Al vincular la sesión al dispositivo, el riesgo de robo _remoto_ de cookies se reduce significativamente. Las empresas pueden considerar duraciones de sesión más largas, sabiendo que las cookies robadas no se pueden actualizar desde otro dispositivo. Sin embargo, DBSC no protege contra el robo del dispositivo, el [malware](https://www.corbado.com/glossary/malware) persistente en el dispositivo ni el abuso por parte de un usuario malintencionado, por lo que las políticas de duración de la sesión aún deben reflejar estos riesgos residuales. ## 3. Panorama de amenazas: la industrialización del robo de cookies Para comprender la urgencia que hay detrás de DBSC, uno debe apreciar la sofisticación del panorama de amenazas moderno. El robo de cookies de sesión ha pasado de ser un truco de hackers de nicho a una industria automatizada y escalable. ### 3.1 El auge de los Infostealers ```mermaid graph TD A[Usuario descarga
software malicioso] -->|Ejecución| B[Infostealer se activa
en el dispositivo] B --> C[Localiza datos del navegador] C --> D[Almacenamiento de cookies
de Chrome/Edge/Firefox] C --> E[Base de datos de contraseñas] C --> F[Billeteras criptográficas] D --> G[Descifra utilizando
credenciales del SO] E --> G F --> G G --> H[Crea un archivo de registro
con datos robados] H --> I[Exfiltra al servidor C2] I --> J[Mercado de la Dark Web] J --> K[Atacante compra el registro] K --> L[Importa la cookie a
su propio navegador] L --> M[Elude la MFA] M --> N[Toma de control de cuenta
completada] style A fill:#ff6b6b,color:#fff style B fill:#ff6b6b,color:#fff style N fill:#ff6b6b,color:#fff style J fill:#495057,color:#fff style M fill:#ffd43b,color:#000 ``` El Malware como Servicio (MaaS) ha reducido la barrera de entrada para los ciberdelincuentes. Los "Infostealers" como RedLine, Raccoon, Vidar y Taurus son cepas de malware disponibles comercialmente diseñadas con un objetivo principal: la exfiltración de datos de los navegadores web. Estos ladrones se distribuyen a través de correos electrónicos de phishing, software crackeado o anuncios maliciosos. Una vez instalados, atacan las rutas de archivos específicas donde navegadores como Chrome, Edge y Firefox almacenan sus datos. - **El objetivo:** La base de datos de cookies (generalmente un archivo [SQLite](https://www.corbado.com/blog/passkey-webauthn-database-guide)) y la base de datos de datos de inicio de sesión (contraseñas guardadas). - **El mecanismo:** Los navegadores cifran estas bases de datos utilizando API de protección de datos (DPAPI en Windows) vinculadas al inicio de sesión del sistema operativo del usuario. Dado que el malware se ejecuta _como el usuario_, puede solicitar trivialmente el descifrado de estos archivos. - **La salida:** El malware genera un "registro" (log), un archivo zip que contiene las cookies, [contraseñas](https://www.corbado.com/es/blog/brecha-datos-lastpass) e información del sistema descifradas y, a veces, claves de billeteras criptográficas. ### 3.2 El mercado de los "Logs" (Registros) Estos registros se agrupan y se venden en [mercados](https://www.corbado.com/passkeys-for-e-commerce) de la dark web como Genesis Market (antes de su cierre) y Russian Market. Los compradores pueden buscar registros que contengan cookies activas para objetivos específicos de alto valor: "Salesforce", "Gmail", "Bank of America" o "[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console". **La evasión:** El valor de un registro de cookies reside en su capacidad para eludir la [Autenticación Multifactor](https://www.corbado.com/es/glossary/cda) (MFA). La mayoría de los [desafíos](https://www.corbado.com/es/blog/passkeys-comprar-vs-desarrollar-guia) de [MFA](https://www.corbado.com/es/blog/contrasenas-complejas-descifradas-pronto) (SMS, TOTP, Push) ocurren solo durante el evento de _inicio de sesión_. Una vez que se establece la sesión y se emite la cookie, el servidor asume que el usuario es de confianza. Un atacante que importa una cookie de sesión válida [se desliza directamente por la puerta de MFA](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc), apareciendo ante el servidor como el usuario que regresa a una pestaña activa. ### 3.3 La amenaza a Google Workspace y Microsoft Entra Las suites de productividad en la nube son objetivos primordiales. Una cookie de sesión robada para una cuenta de Google Workspace o Microsoft Entra ID (anteriormente Azure AD) puede otorgar a un atacante acceso al correo electrónico corporativo, documentos y sistemas internos. [La propia inteligencia de amenazas de Google](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) ha reportado un aumento masivo en el robo de cookies como un vector principal para acceder a las Cuentas de Google, nombrándolo explícitamente como el impulsor de su inversión en DBSC. Señalan que a medida que habilitan obligatoriamente la [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) en dos pasos (2SV) y las claves de acceso, los atacantes simplemente han cambiado las tácticas del phishing de credenciales (que [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / las claves de acceso detienen) al robo de cookies (que [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / las claves de acceso a menudo no detienen). ### 3.4 Límites del "Fingerprinting" de dispositivos Históricamente, los motores de riesgo han intentado detectar el robo de sesiones analizando las huellas dactilares de los dispositivos (fingerprints), observando la cadena de [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), la resolución de pantalla, las fuentes instaladas y la dirección IP. Si de repente aparece una cookie de sesión desde una nueva IP con una huella dactilar de canvas ligeramente diferente, el servidor podría invalidarla. **El problema:** Las iniciativas de privacidad en los navegadores (como Intelligent Tracking Prevention de Safari y Privacy Sandbox de Chrome) están reduciendo activamente la entropía de estas huellas dactilares para detener el seguimiento de anuncios. Esto hace que las huellas dactilares "buenas" para la seguridad sean cada vez más difíciles de aplicar. Además, los atacantes ahora usan navegadores "Anti-Detect" que les permiten falsificar estas huellas dactilares a la perfección para que coincidan con el perfil de la víctima, lo que hace que la detección heurística sea ineficaz. DBSC reemplaza este juego de adivinanzas probabilístico con una prueba criptográfica determinista. ## 4. Arquitectura técnica: cómo funciona DBSC [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) introduce una [API y protocolo estandarizado](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) para crear sesiones vinculadas a una clave en el dispositivo del cliente. La especificación requiere un almacenamiento de claves "robusto frente a la amenaza descrita", pero es independiente en cuanto a la implementación. Chrome utiliza TPM en Windows cuando está disponible. Esta sección detalla la mecánica tal como se define en el borrador de trabajo de W3C y la documentación de Chrome. ### 4.1 Componentes principales | **Componente** | **Descripción** | **Papel en DBSC** | | --------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Agente de usuario (navegador)** | La aplicación cliente (Chrome, Edge, etc.). | Gestiona el par de claves, maneja la interacción con HSM e intercepta las solicitudes de red para adjuntar pruebas. | | **Parte usuaria (servidor)** | La aplicación web (p. ej., portal bancario). | Emite desafíos, verifica firmas y gestiona el ciclo de vida de la sesión. | | **Almacenamiento de claves** | Almacenamiento seguro (TPM, Secure Enclave u otro) | Almacena la clave privada. Chrome utiliza TPM en Windows cuando está disponible; la especificación es independiente de la implementación. | | **Cookie de sesión** | Una cookie HTTP estándar. | Se utiliza como token de portador, pero con una vida útil muy corta (p. ej., de 5 a 10 minutos). | | **Prueba de posesión** | Una firma criptográfica. | Un JWT enviado por el navegador para probar que aún posee la clave privada. | ### 4.2 Ciclo de vida del protocolo DBSC El ciclo de vida de DBSC permite una transición sin problemas de una sesión estándar a una sesión vinculada, asegurando la compatibilidad con versiones anteriores y una mejora progresiva. ```mermaid sequenceDiagram participant User participant Browser participant HSM as HSM (TPM/Secure Enclave) participant Server Note over User,Server: Fase 1: Autenticación y vinculación User->>Browser: Iniciar sesión con credenciales/clave de acceso Browser->>Server: Solicitud de autenticación Server->>Browser: Éxito + Cabecera de registro DBSC Browser->>HSM: Generar par de claves HSM->>Browser: Clave pública/privada (privada no exportable) Browser->>Server: Registrar clave pública (JWT firmado) Server->>Server: Vincular sesión a clave pública Server->>Browser: Cookie de corta duración (5 min) Note over User,Server: Fase 2: Uso normal loop Cada solicitud dentro de 5 minutos Browser->>Server: Solicitud con cookie Server->>Browser: Respuesta end Note over User,Server: Fase 3: Actualización (después de caducar) Browser->>Server: Solicitud con cookie caducada Server->>Browser: 401 + Nonce de desafío Browser->>HSM: Firmar desafío HSM->>Browser: Firma Browser->>Server: Prueba de firma Server->>Server: Verificar con clave pública almacenada Server->>Browser: Nueva cookie de corta duración Browser->>Server: Reintentar solicitud original Server->>Browser: Respuesta de éxito ``` #### 4.2.1 Fase 1: Iniciación y vinculación El proceso de vinculación comienza inmediatamente después de que el usuario se autentica utilizando métodos estándar (contraseña, [clave de acceso](https://www.corbado.com/es/blog/proveedores-passkeys), etc.). 1. **Señal del servidor:** Tras el inicio de sesión exitoso, el servidor establece una cookie de sesión (como de costumbre) pero añade una cabecera específica que indica el soporte de DBSC. ``` HTTP HTTP/1.1 200 OK Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register" ``` - La cabecera Secure-Session-Registration le dice al navegador: "Admito los algoritmos ES256 y RS256. Por favor, registre una sesión vinculada en el endpoint /auth/dbsc/register". 2. **Generación de claves:** El navegador analiza esta cabecera. Genera un nuevo par de claves asimétricas (p. ej., Curva Elíptica P-256), almacenado de forma segura en el dispositivo. - **Nota de implementación:** Chrome utiliza TPM en Windows cuando está disponible; la especificación es independiente del mecanismo de almacenamiento, y solo exige que sea "robusto frente a la amenaza descrita". - **Alcance de privacidad:** La clave se limita al origen web (p. ej., bank.com). El navegador se asegura de que esta clave nunca se utilice para retailer.com, evitando el seguimiento entre sitios. 3. **Solicitud de registro:** El navegador envía una solicitud a la ruta de registro especificada. Esta solicitud incluye la **Clave Pública** recién generada dentro de un JSON Web Token (JWT), firmado por la Clave Privada (atestación autofirmada). ``` HTTP POST /auth/dbsc/register HTTP/1.1 Content-Type: application/jwt \.\.\ ``` 4. **Vinculación de sesión:** El servidor valida la firma para asegurar que la clave pública sea funcional. Luego actualiza su base de datos para asociar la sesión del usuario (session_id=xyz123) con esta Clave Pública específica. A partir de este momento, la sesión queda "vinculada". #### 4.2.2 Fase 2: Bucle de cookies de corta duración Para equilibrar la seguridad con el rendimiento (las operaciones seguras de claves pueden añadir latencia), DBSC utiliza un sistema de token dual. 1. **Emisión:** El servidor emite una _nueva_ cookie de corta duración (p. ej., válida durante 5 minutos). Llamemos a esto access_token. 2. **Uso:** El navegador utiliza este access_token para todas las solicitudes normales (obtención de imágenes, llamadas a la API, navegación de páginas). Mientras la cookie sea válida, no se realizan operaciones criptográficas. Esto asegura que la navegación siga siendo rápida. 3. **Caducidad:** Después de 5 minutos, el access_token caduca. #### 4.2.3 Fase 3: Actualización (Prueba de posesión) Este es el núcleo del mecanismo de seguridad. Cuando la cookie de corta duración caduca, un atacante en un dispositivo diferente queda bloqueado, pero el usuario legítimo (con acceso a la clave vinculada) puede continuar. 1. **Detección:** El navegador intenta realizar una solicitud. Nota que la cookie ha caducado (o el servidor devuelve un 401 o una cabecera específica Secure-Session-Challenge). 2. **Intercepción:** El navegador _pausa_ la solicitud de red. No muestra ningún error al usuario. 3. **Solicitud de actualización:** El navegador llama automáticamente al endpoint de actualización definido en la configuración de la sesión. - El servidor envía un **Desafío** criptográfico (un nonce). - El navegador utiliza la clave vinculada para firmar este desafío. - La firma demuestra la posesión de la clave privada. 4. **Envío:** El navegador devuelve el desafío firmado al servidor. ``` HTTP POST /auth/dbsc/refresh HTTP/1.1 Sec-Secure-Session-Id: \ Secure-Session-Response: \ ``` 5. **Validación:** El servidor utiliza la clave pública almacenada para verificar la firma. - _Si es válida:_ El servidor sabe que la solicitud proviene del mismo dispositivo físico que inició la sesión. Emite un _nuevo_ access_token de corta duración (válido para otros 5 minutos). - _Si no es válida:_ La solicitud es rechazada. Se termina la sesión. 6. **Reanudación:** El navegador toma la nueva cookie y de manera transparente vuelve a intentar la solicitud original que estaba pausada. El [usuario no experimenta ninguna interrupción](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 Matices de implementación #### 4.3.1 Defensa "Lift and Shift" (Copiar y pegar) ```mermaid graph LR subgraph "Dispositivo de la víctima" A[Sesión de usuario
con DBSC] B[Clave privada
HSM/TPM] C[Cookie +
ID de sesión] A --> B A --> C B -.->|No exportable| X[No puede extraer
la clave privada] end subgraph "Escenario de ataque" D[Infostealer RedLine
Infecta dispositivo] D --> E[Roba cookie
e ID de sesión] E --> F[Exporta al
Atacante] end subgraph "Dispositivo del atacante" G[Importa cookie
robada] H[Intenta
Usar sesión] I[El servidor solicita
Actualización DBSC] J[No puede firmar
el desafío] K[Sesión denegada] G --> H H --> I I --> J J --> K end C -.->|Robado| E F --> G style D fill:#ff6b6b,color:#fff style K fill:#51cf66,color:#fff style B fill:#4c6ef5,color:#fff style X fill:#51cf66,color:#fff style J fill:#ff6b6b,color:#fff ``` Considere a un atacante que infecta el equipo del usuario con RedLine Stealer. Roban el `access_token` y el `session_id`. Los importan a su propio navegador. - **Escenario A (Dentro de los 5 minutos):** El atacante podría tener acceso durante unos minutos hasta que el token de corta duración caduque. - **Escenario B (Después de la caducidad):** El navegador del atacante (en un dispositivo diferente) intenta usar el token. El servidor lo rechaza y exige una actualización. El navegador del atacante ve las cabeceras DBSC pero no puede realizar la actualización porque no tiene la clave privada vinculada. El ataque fracasa. #### 4.3.2 Alcance y privacidad La privacidad es un objetivo central de diseño de DBSC. La [especificación de W3C](https://www.w3.org/TR/dbsc/) prohíbe explícitamente el uso de identificadores globales que puedan rastrear a los usuarios en distintos sitios. - **Claves por origen:** El navegador genera un par de claves único para cada sitio. google.com ve la Clave A; amazon.com ve la Clave B. No hay correlación entre ellas. - **Limpieza de usuario:** Si el usuario borra sus cookies/datos de sitios, el navegador también elimina las claves DBSC asociadas. Esto garantiza que DBSC no se pueda utilizar como una "supercookie" para resucitar identidades eliminadas. #### 4.3.3 Consideraciones en el lado del servidor La implementación de DBSC requiere que el servidor mantenga un estado de las claves públicas. - **Esquema de base de datos:** La tabla de sesiones se debe actualizar para almacenar la `public_key` y el `last_challenge` junto al `user_id` y `session_expiry`. - **Rendimiento:** La operación de actualización implica la [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) criptográfica (p. ej., verificar una firma ECDSA). Si bien es rápida, consume más CPU que comprobar una simple cadena. Sin embargo, dado que las actualizaciones solo ocurren cada pocos minutos (no en cada solicitud), la sobrecarga es insignificante. ## 5. Implicaciones comerciales y de producto Más allá de las especificaciones técnicas, DBSC conlleva implicaciones importantes para la estrategia comercial, las hojas de ruta de productos y las posturas de cumplimiento. ### 5.1 El ROI de la seguridad sin fricciones Las iniciativas de seguridad a menudo se consideran centros de costos o generadores de fricción. DBSC da un giro a esta narrativa. El siguiente diagrama ilustra cómo la vinculación de dispositivos crea una cascada de beneficios comerciales: - **Reducción del fraude:** Al neutralizar el vector principal de las tomas de control de cuentas (ATO), las empresas pueden ahorrar millones en pérdidas por fraude. - **Costos de soporte:** La recuperación de cuentas es costosa. [Prevenir el ataque en primer lugar](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) reduce directamente esta carga operativa. - **Optimización de la conversión:** En el [comercio electrónico](https://www.corbado.com/passkeys-for-e-commerce), cada solicitud de inicio de sesión es un posible punto de abandono. DBSC permite políticas agresivas de "mantener la sesión iniciada", habilitando el pago instantáneo sin solicitar la contraseña. ### 5.2 Cumplimiento y el "estado del arte" Los marcos normativos como el [RGPD](https://www.corbado.com/es/blog/manejo-seguro-documentos) (Reglamento General de Protección de Datos) en Europa exigen a las organizaciones implementar "medidas técnicas y organizativas apropiadas" para garantizar la seguridad. - **Seguridad defendible:** A medida que DBSC se convierta en un estándar, probablemente se interpretará como el "estado del arte" en gestión de sesiones. En caso de una brecha, demostrar que se implementó DBSC puede ser una defensa poderosa contra reclamos por negligencia. - **Estándares bancarios (PSD2):** La Directiva de Servicios de [Pago](https://www.corbado.com/passkeys-for-payment) 2 exige la "Autenticación Reforzada de Clientes" (SCA). Si bien la [SCA](https://www.corbado.com/es/blog/psd2-passkeys) se centra en el inicio de sesión, la [vinculación dinámica](https://www.corbado.com/es/blog/vinculacion-dinamica-passkeys-spc) de la sesión al dispositivo se alinea perfectamente con los objetivos de la directiva de vincular la autenticación a montos y beneficiarios específicos. ### 5.3 Garantía alta vs. garantía moderada Los [informes técnicos de la Alianza FIDO](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) destacan el concepto de los "Niveles de garantía" (Assurance Levels). - **Garantía moderada:** Utiliza [claves de acceso sincronizadas](https://www.corbado.com/es/blog/claves-acceso-vinculadas-dispositivo-sincronizadas) (como las de [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)). Excelente para aplicaciones de consumidores, recuperable, fácil de usar. - **Garantía alta:** Requiere claves vinculadas al dispositivo. Aquí es donde brilla DBSC. Para recursos empresariales (portales de RR. HH., repositorios de código) o transacciones [bancarias](https://www.corbado.com/passkeys-for-banking) de alto valor, la organización puede hacer cumplir una política que _solo_ permita el acceso desde sesiones vinculadas a un dispositivo gestionado específico. DBSC proporciona el mecanismo de cumplimiento técnico para esta política. ## 6. DBSC vs. Alternativas Para apreciar completamente a DBSC, debemos compararlo con otras tecnologías que han intentado resolver problemas similares. ```mermaid graph RL subgraph "Cookies tradicionales" TC1[Solo Token de Portador] TC2[Vulnerable al Robo] TC3[Sesiones largas = Riesgo] TC1 --> TC2 TC2 --> TC3 end subgraph "Token Binding" TB1[Vinculación en la capa TLS] TB2[❌ Fracasó: Infraestructura compleja] TB3[Se rompía en los balanceadores de carga] TB1 --> TB2 TB2 --> TB3 end subgraph "DPoP" DP1[Vinculación de tokens OAuth] DP2[✅ Protección de API] DP3[No para sesiones de navegador] DP1 --> DP2 DP2 --> DP3 end subgraph "DBSC" D1[Vinculación en la capa HTTP] D2[✅ Protección de clave de hardware] D3[✅ Funciona con CDN/Load Balancers] D4[✅ Sesiones de navegador] D1 --> D2 D2 --> D3 D3 --> D4 end style TC2 fill:#ff6b6b,color:#fff style TB2 fill:#ff6b6b,color:#fff style D2 fill:#51cf66,color:#fff style D3 fill:#51cf66,color:#fff style D4 fill:#51cf66,color:#fff style DP2 fill:#51cf66,color:#fff ``` ### 6.1 DBSC vs. Token Binding Como se mencionó, el Token Binding intentó vincular la sesión a la capa TLS. - **Token Binding:** Requería soporte del cliente, el servidor, _y_ de todos los saltos intermedios (Equilibradores de carga, Terminadores TLS). Se rompía cuando una conexión se terminaba y se volvía a cifrar. - **DBSC:** [Opera en la capa de aplicación HTTP](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Pasa a través de los equilibradores de carga de forma transparente como cabeceras/cookies estándar. Es mucho más fácil de implementar en arquitecturas modernas de nube (AWS/GCP/Azure) donde el TLS suelen manejarlo las redes de borde del proveedor de la nube. ### 6.2 DBSC vs. DPoP (Demonstrating Proof of Possession) [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) es el estándar para los tokens OAuth "restringidos al remitente". Vincula tanto los tokens de acceso _como_ los tokens de actualización a una clave pública, lo que es crítico, ya que los tokens de actualización son credenciales de portador de larga duración. Cada solicitud de API incluye una prueba DPoP: un [JWT](https://www.corbado.com/es/glossary/jwks) firmado con el método HTTP, la URL, la marca de tiempo y un identificador único. Las especificaciones de alta garantía como [FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) exigen tokens restringidos al remitente; DPoP es el método recomendado cuando el mTLS no está disponible. **La diferencia clave:** Las claves DPoP viven en el contexto de la aplicación. La mejor práctica es utilizar API del SO para almacenamiento no extraíble, pero esto no se aplica estrictamente: muchas implementaciones mantienen las claves en una memoria accesible para JavaScript. Si un atacante puede ejecutar código arbitrario (XSS, malware), puede acceder a las claves DPoP o generar pruebas a demanda. DPoP detiene la reproducción de tokens _entre clientes diferentes_, pero no puede proteger el contexto de un navegador comprometido. DBSC mueve la prueba de posesión al navegador y al hardware. La clave privada vive en un TPM o Secure Enclave que JavaScript no puede leer ni exportar. El navegador maneja el protocolo y produce firmas sin exponer las claves al código de la aplicación. Incluso si la aplicación web está totalmente comprometida, un atacante no puede acuñar nuevas pruebas para las cookies robadas en otra máquina. | Aspecto | DPoP | DBSC | | ---------------------------- | --------------------------------------------------- | ------------------------------ | | **Objetivo** | Tokens de acceso y actualización OAuth | Cookies de sesión de navegador | | **Almacenamiento de claves** | Contexto de aplicación (mejor práctica: API del SO) | Respaldado por hardware (TPM) | | **Resistencia a XSS** | ⚠️ Depende de la implementación | ✅ Claves no exportables | | **Uso principal** | Aplicaciones nativas, SPA, FAPI 2.0 | Sesiones web para usuarios | **Sinergia:** Como [señala la Alianza FIDO](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/), las claves de acceso eliminan el phishing en el inicio de sesión, mientras que DBSC/DPoP protegen los tokens posteriores a la autenticación. Una arquitectura moderna combina ambos: DPoP para las API OAuth (especialmente la [banca](https://www.corbado.com/passkeys-for-banking) abierta regulada), y DBSC para las sesiones del navegador. Juntos cierran el vector de ataque de "copiar y pegar" en todo el ciclo de vida de la sesión. ### 6.3 DBSC vs. Cookies de corta duración (solas) Acortar simplemente la vida útil de las cookies (p. ej., a 15 minutos) mejora la seguridad, pero arruina la UX. Los usuarios se ven obligados a iniciar sesión constantemente. DBSC permite la seguridad _efectiva_ de una cookie de 5 minutos con la _experiencia de usuario_ de una cookie de 30 días. ## 7. Señales compartidas y respuesta dinámica (CAEP/RISC) ```mermaid %%{init: { "theme": "default", "themeVariables": { "actorBkg": "#ffffff", "actorBorder": "#000000", "noteBkgColor": "#f1f3f5", "noteTextColor": "#000000", "activationBkgColor": "#e0e0e0", "actorColours": { "ST": "#ff6b6b", "IdP": "#4c6ef5" } } }}%% sequenceDiagram participant ST as Herramientas de seguridad
(CrowdStrike, Defender) participant IdP as Proveedor de Identidad
(Okta, Google, Azure) participant SP1 as Proveedor de Servicios 1
(Slack) participant SP2 as Proveedor de Servicios 2
(Salesforce) participant SP3 as Proveedor de Servicios 3
(App Bancaria) participant Session as Sesión de Usuario
(Protegida por DBSC) Note over ST,Session: Fase de Detección de Amenazas ST->>ST: Detecta malware en el
dispositivo del usuario ST->>IdP: Señal RISC:
"Dispositivo Comprometido" Note over IdP,SP3: Fase de Propagación de la Señal IdP->>SP1: Evento CAEP:
"Dispositivo Comprometido" IdP->>SP2: Evento CAEP:
"Dispositivo Comprometido" IdP->>SP3: Evento CAEP:
"Dispositivo Comprometido" Note over SP1,Session: Fase de Aplicación (con DBSC) Session->>SP1: Siguiente intento de actualización
(en cuestión de minutos) SP1-->>Session: x Rechazar firma Session->>SP2: Siguiente intento de actualización SP2-->>Session: x Rechazar firma Session->>SP3: Siguiente intento de actualización SP3-->>Session: x Rechazar firma Note over Session: Las sesiones se pueden terminar en el siguiente intento de actualización ``` El potencial de DBSC se amplifica cuando se combina con el [**Marco de Señales Compartidas (SSF)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/), específicamente el **Perfil de Evaluación de Acceso Continuo (CAEP)** y la **Gestión de Riesgos (RISC)**. Nota: SSF/CAEP es una capacidad de ecosistema emergente; el patrón arquitectónico está definido, pero la implementación cruzada entre proveedores todavía está madurando. En el modelo antiguo, si el dispositivo de un usuario se veía comprometido, el Proveedor de Identidad (IdP) no tenía forma de decirle al Proveedor de Servicios (SP) que cancelara la sesión _en ese instante_. El SP tendría que esperar a que caducara la cookie. El flujo DBSC + CAEP que se prevé: 1. **Activación:** Una herramienta de seguridad en el endpoint (como CrowdStrike o Microsoft Defender) detecta malware en la computadora portátil del usuario. 2. **Señal:** La herramienta de seguridad envía una señal RISC al Proveedor de Identidad (p. ej., Okta/Google). 3. **Propagación:** El IdP envía un evento CAEP a las aplicaciones conectadas: "Dispositivo comprometido". 4. **Aplicación (DBSC):** La próxima vez que el navegador intente actualizar la cookie de corta duración DBSC, el servidor rechaza la firma y cancela la sesión.\ Este [patrón arquitectónico](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) permite una revocación más rápida; la latencia real depende del período de actualización del sitio y de si han implementado tanto DBSC como SSF. ## 8. Compatibilidad en navegadores y el ecosistema La adopción de DBSC depende de los proveedores de navegadores. El panorama en 2026 ha cambiado sustancialmente: Chrome pasó DBSC de la prueba de origen a la disponibilidad general en Windows en abril de 2026, y macOS será el siguiente. Otros navegadores aún lo están evaluando. ### 8.1 Google Chrome Google es el principal impulsor de DBSC y el primer navegador en enviarlo de manera generalizada. - **Estado (abril de 2026):** [Chrome 146 lanza DBSC con disponibilidad general en Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), poniendo fin a la fase de Prueba de Origen. Se anuncia que la compatibilidad con macOS, utilizando Secure Enclave, llegará en un próximo lanzamiento de Chrome. - **Hardware:** Windows utiliza TPM, macOS utilizará Secure Enclave. Google ha declarado que también está explorando **claves basadas en software** para extender la protección de DBSC a los dispositivos sin hardware seguro dedicado. - **Hoja de ruta:** El anuncio de disponibilidad general de Google también publicó la hoja de ruta del próximo paso: - **Protección de la identidad federada:** vinculaciones DBSC de [origen cruzado](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn) para que la sesión de la parte usuaria (RP) permanezca vinculada a la misma clave de dispositivo que la sesión del proveedor de identidad (IdP), preservando una cadena de confianza ininterrumpida a través de [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso). - **Registro avanzado:** vinculación de sesiones DBSC a material de claves de confianza preexistente, como **certificados mTLS** o **claves de seguridad de hardware**, en lugar de generar una clave nueva en el momento de iniciar sesión. - **Compatibilidad con más dispositivos:** claves basadas en software para dispositivos sin TPM / Secure Enclave. - **Resultados operativos:** Durante la implementación, Google informa una "reducción significativa en el robo de sesiones" para las sesiones protegidas por DBSC. - **Cuentas de Google:** Por separado, Google ya había implementado la protección de estilo DBSC para [cookies de cuentas de Google en Chrome para Windows](https://support.google.com/chrome/a/answer/2657289), controlada a través de la política empresarial. Esto protege a Gmail/Workspace y ahora es la misma familia tecnológica que tiene disponibilidad general para la web en general. ### 8.2 Microsoft Edge y Windows Microsoft está participando activamente. - **Estado:** Edge ejecutó una [Prueba de Origen DBSC](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) en Windows que finalizó en octubre de 2025. No se ha anunciado una prueba de reemplazo ni disponibilidad general. - **Contexto empresarial:** Edge utiliza la [arquitectura de "Primary Refresh Token" (PRT)](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) para el [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) de Entra/Azure AD, que es conceptualmente similar a DBSC. El PRT sigue siendo un mecanismo específico de Microsoft; no hay un plan anunciado para unificarlo con el estándar web DBSC para sitios de terceros. ### 8.3 Apple Safari (WebKit) La postura de Apple es fundamental para la cobertura móvil. - **Estado:** WebKit tiene un [incidente sobre la posición en los estándares](https://github.com/WebKit/standards-positions/issues/281) que evalúa a DBSC observando preocupaciones de usabilidad/privacidad. Las notas de lanzamiento de Safari no mencionan DBSC. No existe una declaración pública que indique que se está "implementando activamente". - **La privacidad ante todo:** La principal preocupación de Apple es que DBSC podría utilizarse para "supercookies" (seguimiento imborrable). La especificación W3C aborda esto asegurando que las claves se eliminen con los datos del sitio web. - **Participación:** WebKit está participando en el proceso estándar, pero el estado de la implementación no está claro: "en discusión" en lugar de "en desarrollo". ### 8.4 Mozilla Firefox Mozilla tiene un [incidente sobre la posición en los estándares](https://github.com/mozilla/standards-positions/issues/912) que evalúa a DBSC observando preocupaciones sobre la complejidad y la privacidad. No hay un compromiso público para implementarlo una vez que el estándar se estabilice. ## 9. Recomendaciones: cómo proteger a los usuarios hoy Dado el nivel de compatibilidad actual del ecosistema con DBSC y las claves de acceso, las organizaciones deben adoptar un enfoque por fases para implementar estas tecnologías complementarias. La hoja de ruta a continuación describe acciones inmediatas y los hitos de planificación estratégica: ### 9.1 Acciones inmediatas (ahora que Chrome 146 cuenta con disponibilidad general) 1. **Implementar primero las claves de acceso**: Comience con la implementación de las claves de acceso para asegurar la capa de autenticación. Esto proporciona protección inmediata contra el phishing de credenciales y es el requisito previo para obtener un valor real de DBSC. 2. **Lanzar los endpoints de registro y actualización DBSC**: Con la disponibilidad general en Chrome 146, el trabajo real es ahora la integración del backend: agregar las cabeceras `Secure-Session-Registration` en las respuestas de inicio de sesión e implementar `/dbsc/register` junto con un endpoint de actualización que verifique los [desafíos](https://www.corbado.com/es/blog/passkeys-comprar-vs-desarrollar-guia) firmados. No es necesario modificar el código del frontend. 3. **Implementar sesiones de corta duración con tokens de actualización**: Si aún no está listo para DBSC, adopte el patrón arquitectónico de tokens de corta duración con mecanismos de actualización. Esto prepara su backend para DBSC al mismo tiempo que mejora la seguridad actual. ### 9.2 Planificación estratégica (próximos 12 meses) 1. **Adoptar un enfoque híbrido**: Utilice la detección de características para servir DBSC a los navegadores capaces (actualmente Chrome 146+ en Windows, Secure Enclave en macOS próximamente) mientras mantiene opciones de reserva (fallbacks). Esto maximiza la seguridad sin excluir a los usuarios de Safari, Firefox o Edge. 2. **Prepararse para los próximos elementos de la hoja de ruta**: Google ha mencionado explícitamente la identidad federada (vinculaciones SSO de [origen cruzado](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn)), el registro avanzado (mTLS / claves de hardware) y las claves basadas en software para una mayor cobertura de dispositivos. Si opera una capa de SSO o IdP, comience a planificar el enlace de origen cruzado ahora. 3. **Integrarse con Proveedores de Identidad**: Si usa Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) u otros IdP similares, trabaje con ellos para habilitar el soporte de DBSC en sus SDK. Muchos participaron en las Pruebas de Origen y están lanzando activamente las capacidades DBSC ahora que Chrome cuenta con disponibilidad general. ### 9.3 Mejores prácticas de implementación - **Comenzar con objetivos de alto valor**: Priorice DBSC para los paneles de administración, las transacciones financieras y el acceso a datos sensibles. - **Utilizar soluciones gestionadas**: Considere plataformas como Corbado, que manejan la complejidad de la implementación de DBSC y la compatibilidad de los navegadores. - **Medir e iterar**: Haga un seguimiento de métricas como intentos de secuestro de sesiones, tickets de soporte y fricción del usuario para demostrar el ROI. - **Prepararse para el cumplimiento normativo**: Documente su implementación DBSC, ya que probablemente se convertirá en un requisito de cumplimiento para el manejo de datos sensibles. ## 10. Cómo puede ayudar Corbado: el puente hacia el futuro Implementar DBSC desde cero supone una gran carga de ingeniería. Requiere experiencia criptográfica, un profundo conocimiento de las inconsistencias del navegador y una sólida infraestructura del lado del servidor para gestionar claves y [desafíos](https://www.corbado.com/es/blog/passkeys-comprar-vs-desarrollar-guia). Aquí es donde **Corbado** actúa como un habilitador. ### 10.1 La base: las claves de acceso No se puede construir una sesión de alta garantía sobre un inicio de sesión de baja garantía. Si un usuario inicia sesión con una contraseña débil, la sesión es tan segura como esa contraseña. El producto principal de Corbado (**claves de acceso gestionadas**) proporciona la base necesaria. Al integrar Corbado, las organizaciones pueden implementar claves de acceso fácilmente, asegurando que el inicio de la sesión sea resistente al phishing. ### 10.2 El futuro: DBSC para la detección de dispositivos de confianza Corbado aprovechará DBSC para mejorar la detección de dispositivos de confianza. Cuando las señales DBSC estén disponibles, proporcionarán una prueba criptográfica de que una sesión se origina desde un dispositivo específico, lo que permitirá a Corbado aumentar los niveles de confianza de autenticación en consecuencia. - **Resolviendo la ambigüedad de las claves de acceso sincronizadas:** Las [claves de acceso sincronizadas](https://www.corbado.com/es/blog/claves-acceso-vinculadas-dispositivo-sincronizadas) son convenientes pero crean una brecha de confianza: cuando un usuario se autentica con una [clave de acceso](https://www.corbado.com/es/blog/proveedores-passkeys) sincronizada, no se puede saber si es su computadora portátil habitual o un dispositivo nuevo que acaba de sincronizar la credencial. DBSC cierra esta brecha. Al verificar si el dispositivo tiene una vinculación DBSC establecida, Corbado puede comprobar que el dispositivo sea realmente conocido y confiable, no solo una sincronización por primera vez. - **Mayor confianza para los dispositivos conocidos:** Cuando las señales DBSC confirman que un dispositivo ha sido visto antes, Corbado puede tomar decisiones de riesgo con mayor confianza: menos solicitudes de autenticación escalonadas (step-up) para usuarios legítimos que regresan, y un escrutinio más estricto para las sesiones de dispositivos no reconocidos. - **Complementando la inteligencia de las claves de acceso:** Las señales DBSC se integran con el motor de [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) existente de Corbado. La combinación de la autenticación basada en claves de acceso y la vinculación del dispositivo basada en DBSC crea una cadena de confianza completa desde el inicio de sesión hasta todo el ciclo de vida de la sesión. Para preguntas sobre cómo planea Corbado integrar DBSC en su plataforma, [comuníquese con el equipo](https://www.corbado.com/contact). ### 10.3 Reserva elegante (la realidad "híbrida") Durante los próximos años, la web será híbrida. Algunos usuarios tendrán navegadores compatibles con DBSC (Chrome en [Windows 11](https://www.corbado.com/blog/passkeys-windows-11)); otros estarán en sistemas más antiguos. Manejar esta fragmentación es difícil. El motor de [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) de Corbado está diseñado para manejar exactamente este tipo de lógica de reserva, ofreciendo claves de acceso a dispositivos capaces y opciones de reserva a otros. Esta misma inteligencia se aplica a la vinculación de sesiones, asegurando que la seguridad se maximice para cada usuario de acuerdo con las capacidades de su dispositivo. ## 11. Conclusión: el camino a seguir para DBSC La era del "Token de portador" está llegando a su fin. La gestión de sesiones actual está fallando estrepitosamente: los tokens de portador pueden ser robados por operaciones de malware a escala industrial y utilizados desde cualquier dispositivo, lo que permite la toma de control de cuentas que eluden incluso los métodos de autenticación más sólidos. Esta vulnerabilidad fundamental ha creado una economía sumergida que vale miles de millones. [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) representa la respuesta emergente de la industria. A diferencia de las cookies seguras tradicionales con sus banderas HttpOnly y secretos estáticos, DBSC añade una prueba de posesión criptográfica a través de claves vinculadas al dispositivo. Esto hace que las cookies robadas sean mucho menos valiosas. No se pueden actualizar desde otro dispositivo. Mientras que el Token Binding fracasó al exigir cambios complejos en la capa TLS en toda la infraestructura, DBSC triunfa al operar en la capa de aplicación HTTP, siendo compatible con los equilibradores de carga y las arquitecturas de CDN existentes. Nota: DBSC tiene rutas de reserva documentadas donde el navegador omite la vinculación (TPM no disponible, errores de red), por lo que reduce en gran medida el riesgo de robo de cookies, aunque no lo elimina. La sinergia entre DBSC y las claves de acceso eleva significativamente el estándar frente a los atacantes en todo el recorrido del usuario. Las claves de acceso eliminan el phishing de credenciales en el inicio de sesión, mientras que DBSC dificulta enormemente el secuestro de sesiones a través del robo remoto de cookies, formando juntos el marco de identidad de "alta garantía" que concibe la Alianza [FIDO](https://www.corbado.com/es/glossary/cda). Con la [disponibilidad general de DBSC que trae Chrome 146 para Windows en abril de 2026](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) y la compatibilidad con Secure Enclave en macOS próximamente, el estándar ha pasado de la fase de preparación a la fase de despliegue. La hoja de ruta publicada por Google (identidad federada, registro de mTLS / claves de hardware, claves basadas en software) señala los próximos 12 meses de expansión. Para los gerentes de producto, el caso de negocios es convincente: DBSC permite sesiones seguras "infinitas" que reducen drásticamente la fricción de inicio de sesión, al mismo tiempo que reducen las pérdidas por fraude y los costos de soporte. El ROI se manifiesta en mayores tasas de conversión, menos tickets de restablecimiento de contraseña y la eliminación de incidentes de toma de cuentas. Las organizaciones que utilizan OAuth pueden aprovechar el mismo concepto de vinculación de claves a través de DPoP para los tokens de API, mientras que la integración con Shared Signals (CAEP/RISC) permite una respuesta a amenazas en tiempo real, revocando instantáneamente las sesiones comprometidas en el próximo intento de actualización. La implementación no requiere construir desde cero. Plataformas como [Corbado](https://www.corbado.com/features) proporcionan infraestructura de claves de acceso y están haciendo un seguimiento a los desarrollos de DBSC para integrar la vinculación de dispositivos a medida que madure la compatibilidad con los navegadores. La [especificación de W3C](https://www.w3.org/TR/dbsc/) es un Borrador de Trabajo activo, Chrome 146 está en disponibilidad general (GA) en Windows y se implementará en macOS, y otros navegadores todavía están evaluando el estándar. La trayectoria es clara: las organizaciones que comiencen a adoptar las claves de acceso y DBSC hoy estarán mejor posicionadas para un futuro [sin contraseñas](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) y resistente al phishing. La cuestión no es si implementar sesiones vinculadas al dispositivo, sino cuán rápido puede implementarlas para proteger a sus usuarios y su negocio. El futuro de la seguridad web no es solo ser autenticado; es estar vinculado criptográficamente a los dispositivos en los que confiamos. ## Preguntas frecuentes ### ¿Cómo funciona DBSC con CAEP y RISC para revocar sesiones comprometidas en tiempo real? Cuando las herramientas de seguridad de endpoints como CrowdStrike detectan malware, envían una señal RISC al Proveedor de Identidad, que envía un evento CAEP de "Dispositivo comprometido" a las aplicaciones conectadas. En el próximo intento de actualización de DBSC (en cuestión de minutos), esas aplicaciones rechazan la firma de la sesión y cancelan el acceso. La implementación cruzada de CAEP/RISC entre proveedores aún está madurando. ### ¿Cuál es la diferencia entre DBSC y DPoP para proteger las sesiones de aplicaciones web? DPoP (RFC 9449) vincula el acceso de OAuth y los tokens de actualización a una clave pública en la capa de aplicación, protegiendo principalmente las llamadas a la API en aplicaciones nativas y SPA. DBSC vincula las cookies de sesión del navegador a claves TPM respaldadas por hardware que JavaScript no puede leer ni exportar, protegiendo las sesiones orientadas al usuario, incluso cuando la propia aplicación web se ve comprometida por un XSS o malware. ### ¿Por qué DBSC permite duraciones de sesión más largas sin aumentar el riesgo de seguridad? El diseño de seguridad tradicional exige tiempos de espera de sesión cortos para limitar los daños en caso de que una cookie se robe y se reproduzca de forma remota. DBSC vincula la capacidad de actualización a la clave privada del dispositivo de origen, de modo que una cookie robada y utilizada desde un dispositivo diferente no supera el desafío criptográfico. Las sesiones pueden ser efectivamente indefinidas porque los ataques de reproducción remota quedan neutralizados. ### ¿Qué ROI comercial pueden esperar las empresas al implementar DBSC? DBSC neutraliza el robo de cookies como el vector principal en la Toma de control de cuenta, reduciendo directamente las pérdidas por fraude y los costos de soporte de recuperación de cuentas. Las sesiones largas y seguras eliminan las continuas solicitudes de inicio de sesión, mejorando las tasas de conversión en el comercio electrónico y reduciendo el abandono. La Alianza [FIDO](https://www.corbado.com/es/glossary/cda) posiciona a DBSC como una herramienta que eleva la seguridad a la vez que reduce la fricción del usuario.