Respuesta rápida: implementa DBSC donde puedas. Es una buena protección gratuita contra el reenvío de cookies robadas en Chrome. Pero DBSC hace un solo trabajo concreto: es solo para Chrome, posterior al login, antirrobo más que antifraude, y está diseñado con criterios de privacidad para no darte ninguna identidad del dispositivo. La huella digital del dispositivo responde una pregunta distinta, y DBSC está hecho deliberadamente para no responderla. Tratar a DBSC como reemplazo de la huella digital es un error de categoría.
Device Bound Session Credentials (DBSC) de Google llegó a disponibilidad general en Chrome 146 en Windows el 2026-04-10. En cuanto se lanzó, una pregunta justa cayó sobre cada equipo de fraude y seguridad: si Chrome ahora vincula las sesiones al dispositivo de forma gratuita, ¿para qué pagar por huella digital?
La respuesta honesta empieza con una concesión. Para su único trabajo, DBSC es realmente sólido, más sólido que una huella digital. El resto de este artículo trata de todo lo que ese trabajo no incluye.
Qué es DBSC, ahora que está en disponibilidad general
DBSC vincula una sesión a una clave privada alojada en el hardware seguro del dispositivo, un TPM en Windows o el Secure Enclave en macOS. La clave no se puede exportar. Aproximadamente cada cinco minutos, el navegador demuestra que aún posee esa clave, y solo entonces el servidor renueva una cookie de corta duración. Roba la cookie y muévela a otra máquina, y muere, porque el ladrón no puede reproducir la prueba vinculada al hardware.
Eso cierra exactamente la ventana de reenvío que explotan a gran escala el malware infostealer y los kits de phishing de adversario en el medio. Para profundizar en por qué la sesión del navegador se convirtió en un plano de control, consulta la sesión del navegador es ahora un plano de control de seguridad.
Dónde DBSC es realmente mejor
Para hacer que una cookie robada sea inútil en otro dispositivo, la vinculación criptográfica por hardware supera a una huella digital, y vale la pena decirlo con claridad.
Una huella digital es señal observable. Un atacante decidido en un dispositivo similar puede imitar lo suficiente como para parecer la víctima. En nuestras propias pruebas, las defensas contra bots basadas en huella digital invalidan con dureza el reenvío automatizado pero quedan blandas ante un atacante humano que reenvía una cookie robada desde un dispositivo similar. Una clave privada vinculada al TPM no tiene ese borde blando: no se puede extraer, así que el reenvío simplemente falla.
Por eso cside no afirma ser mejor para detener el robo de cookies. Para esa porción, no lo es. Concede el punto y sube un nivel, porque el nivel de arriba es donde vive la mayor parte del fraude.
DBSC frente a huella digital del dispositivo de un vistazo
| Ataque o necesidad | DBSC | Huella digital del dispositivo (cside) |
|---|---|---|
| Cookie robada reenviada fuera del dispositivo | Fuerte: la clave de hardware no se puede reproducir | Parcial: detecta el cambio de dispositivo, se puede imitar |
| Robo de credenciales y phishing | Ninguna: también vincula el dispositivo del atacante | Marca credenciales válidas en un dispositivo nuevo |
| Relleno de credenciales | Ninguna: opera después del login | Detecta patrones automatizados y de dispositivo repetido |
| Fraude de cuentas nuevas y sintéticas | Ninguna: aún no existe sesión | Funciona en el registro |
| Registros de bots, scraping, carding | Ninguna | Caso de uso principal, previo a la autenticación |
| Entre cuentas y multicuenta | Ninguna: las claves no son correlacionables por diseño | Vincula dispositivos entre cuentas |
| Reputación del dispositivo y puntaje de riesgo | Ninguna | Sí |
| Cobertura de navegadores | Chrome en Windows hoy | Todos los navegadores, cada visitante |
| Implementación | Rearquitectura de la sesión en el servidor | Integración directa en la ruta del script de origen |
| Visibilidad para los atacantes | Protocolo público y detectable | Estructuralmente invisible en la ruta de origen |
Por qué sigues necesitando la huella digital del dispositivo
DBSC vincula a quien inicie sesión, incluido el atacante
Este es el punto que más importa. DBSC defiende contra el robo de cookies, donde el malware toma una sesión que ya pertenece a la víctima. No hace nada contra el robo de credenciales, el phishing ni el relleno de credenciales. Si un atacante tiene la contraseña, DBSC le emite alegremente una sesión limpia, vinculada a su dispositivo. La vinculación es real. Solo que está vinculada a la persona equivocada.
La huella digital es lo que detecta la ruta real del robo de cuentas: credenciales válidas que llegan desde un dispositivo nuevo. DBSC bendice precisamente el caso que la huella digital está hecha para marcar. Para conocer toda la cadena de ataque, consulta comparación de soluciones para la prevención del robo de cuentas.
DBSC solo funciona después del login
El fraude ocurre antes de que haya una sesión que vincular. El fraude de cuentas nuevas, las identidades sintéticas, los registros de bots, los intentos de relleno de credenciales, el scraping, el carding y el abuso de bonos son todos eventos previos a la autenticación o entre cuentas. Todavía no hay una credencial de sesión que vincular criptográficamente, así que DBSC no tiene nada sobre lo que actuar.
La huella digital funciona en el registro, el inicio de sesión, el pago y el restablecimiento de contraseña, los momentos donde se decide el abuso previo a la autenticación.
DBSC está diseñado para no ser una capa de identidad del dispositivo
Esto es una característica, no una carencia, y conviene entenderlo bien. Las claves de DBSC son por sesión, por origen y deliberadamente no correlacionables, precisamente para que el mecanismo no pueda convertirse en un vector de seguimiento o vinculación. Eso es bueno para los usuarios.
También es un muro duro para los equipos de fraude. DBSC te dirá "mismo navegador que al inicio de la sesión, sí o no", y nada más. Sin reputación del dispositivo. Sin "este dispositivo está detrás de 50 cuentas". Sin vinculación entre cuentas. Sin puntaje de riesgo. Incluso donde DBSC está totalmente implementado, sigues necesitando una capa de identificación del dispositivo aparte, porque DBSC se niega a serlo.
Cobertura: Chrome en Windows hoy
DBSC está en disponibilidad general en Chrome en Windows. El soporte para macOS mediante el Secure Enclave todavía está por llegar. Edge realizó una prueba de origen sin disponibilidad general. Safari y Firefox no lo están implementando. En iOS Safari y en Firefox, eso es cero protección.
La huella digital de cside funciona en todos los navegadores, para cada visitante, sin muestreo. Ve la solicitud real en la ruta real sin importar qué lance cada proveedor a continuación.
La realidad de la implementación
DBSC no es un interruptor. Cada sitio tiene que rearquitecturar su capa de sesión del lado del servidor: registro de claves, puntos de actualización, manejo del ciclo de vida y alternativas para navegadores no compatibles. Por eso, un trimestre después de la disponibilidad general, la lista pública de partes que dependen de él es esencialmente Google y Okta.
La huella digital de cside es una integración directa en la ruta de JavaScript de origen existente. El plazo es de semanas, no un programa de seguridad de varios trimestres.
La diferencia arquitectónica: de origen, sin muestreo, invisible para los atacantes
cside recopila a través del proxy de origen en la ruta de entrega del script. De ahí se derivan dos cosas.
Es sin muestreo y universal. Cada visitante real, sobre la carga útil real entregada a usuarios reales, no una porción muestreada de un SDK que parte del tráfico nunca carga.
Es estructuralmente invisible para los atacantes. No hay un origen de SDK de terceros que rastrear ni una solicitud aparte que bloquear. Cuando probamos grandes bancos y aseguradoras de EE. UU., su identificación de dispositivo se ejecutaba de origen y permanecía invisible para BuiltWith, Wappalyzer y los escaneos estáticos estándar. Solo un renderizado real en el navegador lo revelaba.
DBSC es lo opuesto por diseño: un protocolo público, bien documentado y detectable. Un atacante puede ver exactamente cuándo DBSC está en juego y rodear los casos que no cubre, una sesión de Safari, un flujo previo al login o una sesión recién obtenida por phishing en su propio dispositivo.
Control del proveedor
"Solo usa la función de Google" significa externalizar tu hoja de ruta de confianza de sesión a las decisiones de diseño de Chrome y a navegadores que no controlas. La cobertura, el modelo de privacidad y el calendario de lanzamiento se deciden en otro lugar. Una capa independiente del navegador que tú controlas mantiene ese control en casa.
La forma correcta de usar DBSC y la huella digital juntos
La posición creíble es complementaria, no excluyente.
Implementa DBSC donde puedas. Es buena protección gratuita contra el robo de cookies en Chrome, y lleva una señal mayor: toda la industria se está moviendo hacia la confianza vinculada al dispositivo. Eso valida la tesis y tiende a expandir el presupuesto para ella.
Luego cubre lo que DBSC estructuralmente no puede: todos los navegadores, desde antes del login hasta el pago, el fraude entre cuentas, el abuso de bots y agentes de IA, la detección de VPN y proxy y la evidencia de contracargos. Que DBSC llegue a disponibilidad general no cierra esa brecha. Refuerza el argumento para cerrarla.
Qué hacer esta semana
- Activa DBSC donde tu stack y los navegadores de tus usuarios lo admitan. Trátalo como protección gratuita contra el robo de cookies para Chrome en Windows, no como tu estrategia de confianza de sesión.
- Añade una capa de dispositivo independiente del navegador que se ejecute antes del login y entre cuentas, para que el fraude de registro, el relleno de credenciales y el robo desde un dispositivo nuevo sean visibles en todos los navegadores.
- Conecta una discrepancia de dispositivo a una acción. Una huella digital que no coincida con la base establecida en el login debería disparar una autenticación reforzada o terminar la sesión, no solo registrar una línea.
- Revisa tu cobertura fuera de Chrome. Si los usuarios de iOS Safari y Firefox no tienen validación de sesión consciente del dispositivo, ahí es donde aterriza el próximo reenvío.
Cómo encaja cside
La huella digital de dispositivo de cside recopila más de 100 señales de navegador, dispositivo y red en la ruta de origen para construir un identificador persistente de cada visitante, en cada navegador. Funciona antes de que haya una sesión que vincular, enlaza dispositivos entre cuentas, puntúa el riesgo y alimenta una discrepancia a tu motor de reglas o proveedor de identidad existente.
DBSC te dice si la cookie volvió desde el mismo dispositivo. cside te dice quién es el dispositivo, qué ha hecho en tus cuentas y si confiar en él, desde la primera solicitud hasta el pago.
A fecha de 2026-06-09. La disponibilidad de DBSC y el soporte de navegadores están cambiando rápidamente; verifica el estado actual del lanzamiento con las fuentes de Google y de los proveedores de navegadores antes de depender de la cobertura.
Solicita una demo para ver cómo cside cubre el fraude que DBSC nunca fue creado para detener.
