Explicación de las Device Bound Session Credentials (DBSC)

Whitepaper empresarial de Passkeys. Guías prácticas, patrones de despliegue y KPIs para programas de passkeys.

Obtener whitepaper

Estado de compatibilidad en navegadores

Leyenda: ✅ Disponibilidad general | 🚧 Anunciado / en desarrollo | ⏸️ Prueba finalizada | 🔄 Evaluando/monitoreando | ❌ Aún no disponible

Nota: 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 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

La arquitectura de la World Wide Web 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 y almacenado en la computadora del usuario, para ser enviado de vuelta al sitio web 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 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 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 mediante la adopción de los estándares FIDO (Fast Identity Online) y las claves de acceso (passkeys), los atacantes están cambiando su enfoque hacia la "puerta trasera": la sesión activa. Hacer 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 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. Con Chrome 146 (abril de 2026) lanzando DBSC en disponibilidad general para Windows, 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 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, diseñado para arquitectos de seguridad, gerentes de producto y desarrolladores. Explora la arquitectura técnica, las implicaciones comerciales de la "seguridad 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 para lograr una mayor resistencia al 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?
9. ¿Cómo se integra DBSC con Shared Signals (CAEP/RISC) para una respuesta a amenazas en tiempo real?

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.

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 (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 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), 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.

DBSC introduce un segundo factor de autenticación 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 "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.

Las claves de acceso 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 y, por lo tanto, eliminando el 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 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 con acceso continuo al dispositivo o ataques en tiempo real de intermediario en el navegador (browser-in-the-middle) en el mismo dispositivo.

Cómo funcionan en conjunto las claves de acceso y DBSC

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). 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.

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 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.

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.

graph TD
    A[Usuario descarga<br/>software malicioso] -->|Ejecución| B[Infostealer se activa<br/>en el dispositivo]
    B --> C[Localiza datos del navegador]
    C --> D[Almacenamiento de cookies<br/>de Chrome/Edge/Firefox]
    C --> E[Base de datos de contraseñas]
    C --> F[Billeteras criptográficas]

    D --> G[Descifra utilizando<br/>credenciales del SO]
    E --> G
    F --> G

    G --> H[Crea un archivo de registro<br/>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<br/>su propio navegador]
    L --> M[Elude la MFA]
    M --> N[Toma de control de cuenta<br/>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) 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 e información del sistema descifradas y, a veces, claves de billeteras criptográficas.

Estos registros se agrupan y se venden en mercados 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 Console".

La evasión: El valor de un registro de cookies reside en su capacidad para eludir la Autenticación Multifactor (MFA). La mayoría de los desafíos de MFA (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, apareciendo ante el servidor como el usuario que regresa a una pestaña activa.

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 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 en dos pasos (2SV) y las claves de acceso, los atacantes simplemente han cambiado las tácticas del phishing de credenciales (que 2SV / las claves de acceso detienen) al robo de cookies (que 2SV / las claves de acceso a menudo no detienen).

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, 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.

Device Bound Session Credentials (DBSC) introduce una API y protocolo estandarizado 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.

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.

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

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, 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
   
   \<Cabecera JWT\>.\<Carga útil JWT que contiene clave pública\>.\<Firma\>
   

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".

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.

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: \<ID de sesión\>
   Secure-Session-Response: \<Firma JWT del desafío\>
   

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.

graph LR
    subgraph "Dispositivo de la víctima"
        A[Sesión de usuario<br/>con DBSC]
        B[Clave privada<br/>HSM/TPM]
        C[Cookie +<br/>ID de sesión]
        A --> B
        A --> C
        B -.->|No exportable| X[No puede extraer<br/>la clave privada]
    end

    subgraph "Escenario de ataque"
        D[Infostealer RedLine<br/>Infecta dispositivo]
        D --> E[Roba cookie<br/>e ID de sesión]
        E --> F[Exporta al<br/>Atacante]
    end

    subgraph "Dispositivo del atacante"
        G[Importa cookie<br/>robada]
        H[Intenta<br/>Usar sesión]
        I[El servidor solicita<br/>Actualización DBSC]
        J[No puede firmar<br/>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.

La privacidad es un objetivo central de diseño de DBSC. La especificación de W3C 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.

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 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.

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.

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 reduce directamente esta carga operativa.
• Optimización de la conversión: En el comercio electrónico, 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.

Los marcos normativos como el RGPD (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 2 exige la "Autenticación Reforzada de Clientes" (SCA). Si bien la SCA se centra en el inicio de sesión, la vinculación dinámica 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.

Los informes técnicos de la Alianza FIDO destacan el concepto de los "Niveles de garantía" (Assurance Levels).

• Garantía moderada: Utiliza claves de acceso sincronizadas (como las de 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 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.

Para apreciar completamente a DBSC, debemos compararlo con otras tecnologías que han intentado resolver problemas similares.

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

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. 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.

DPoP (RFC 9449) 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 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 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.

Sinergia: Como señala la Alianza FIDO, 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 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.

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.

%%{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<br/>(CrowdStrike, Defender)
    participant IdP as Proveedor de Identidad<br/>(Okta, Google, Azure)
    participant SP1 as Proveedor de Servicios 1<br/>(Slack)
    participant SP2 as Proveedor de Servicios 2<br/>(Salesforce)
    participant SP3 as Proveedor de Servicios 3<br/>(App Bancaria)
    participant Session as Sesión de Usuario<br/>(Protegida por DBSC)

    Note over ST,Session: Fase de Detección de Amenazas
    ST->>ST: Detecta malware en el<br/>dispositivo del usuario
    ST->>IdP: Señal RISC:<br/>"Dispositivo Comprometido"

    Note over IdP,SP3: Fase de Propagación de la Señal
    IdP->>SP1: Evento CAEP:<br/>"Dispositivo Comprometido"
    IdP->>SP2: Evento CAEP:<br/>"Dispositivo Comprometido"
    IdP->>SP3: Evento CAEP:<br/>"Dispositivo Comprometido"

    Note over SP1,Session: Fase de Aplicación (con DBSC)
    Session->>SP1: Siguiente intento de actualización<br/>(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), 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 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.

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.

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, 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 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.
  • 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, 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.

Microsoft está participando activamente.

• Estado: Edge ejecutó una Prueba de Origen DBSC 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) para el 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.

La postura de Apple es fundamental para la cobertura móvil.

• Estado: WebKit tiene un incidente sobre la posición en los estándares 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".

Mozilla tiene un incidente sobre la posición en los estándares 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.

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:

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 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.

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), 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 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.

• 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.

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. Aquí es donde Corbado actúa como un habilitador.

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.

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 son convenientes pero crean una brecha de confianza: cuando un usuario se autentica con una clave de acceso 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 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.

Durante los próximos años, la web será híbrida. Algunos usuarios tendrán navegadores compatibles con DBSC (Chrome en Windows 11); otros estarán en sistemas más antiguos. Manejar esta fragmentación es difícil. El motor de 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.

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 (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. Con la disponibilidad general de DBSC que trae Chrome 146 para Windows en abril de 2026 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 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 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 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.

Acerca de Corbado

Corbado es la Passkey Intelligence Platform para equipos de CIAM que gestionan autenticación de consumidores a gran escala. Te ayudamos a ver lo que los logs de tu IDP y las herramientas de analytics genéricas no muestran: qué dispositivos, versiones de SO, navegadores y gestores de credenciales soportan passkeys, por qué los registros no se convierten en inicios de sesión, dónde falla el flujo de WebAuthn y cuándo una actualización de SO o navegador rompe el login en silencio — todo sin reemplazar Okta, Auth0, Ping, Cognito o tu IDP propio. Dos productos: Corbado Observe aporta observabilidad para passkeys y cualquier otro método de login. Corbado Connect añade passkeys gestionados con analytics integrado (junto a tu IDP). VicRoads ejecuta passkeys para más de 5M de usuarios con Corbado (+80 % de activación de passkey). Habla con un experto en Passkeys →

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.

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.

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.

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 posiciona a DBSC como una herramienta que eleva la seguridad a la vez que reduce la fricción del usuario.