Skip to main content

Los inicios de sesión bancarios están reforzados. Las sesiones, todavía no.

Los bancos están entre las plataformas de consumo más atacadas por phishing y más maduras en seguridad de la web. Analizamos los 43 bancos de consumo más maduros en seguridad de EE. UU., Reino Unido, eurozona, Canadá, Australia y los países nórdicos. Ninguno vincula criptográficamente la sesión de navegador en vivo al dispositivo que la creó.

Estos bancos ya emplean una fuerte inteligencia de dispositivo: biometría conductual, defensa contra bots, perfilado de dispositivos, atestación de la app móvil. Pero puntuar un dispositivo no es lo mismo que vincular la sesión. La cookie posterior al inicio de sesión sigue siendo un token bearer: quien la tenga es tratado como el usuario. Una sesión robada mediante phishing, un infostealer o un kit de adversary-in-the-middle funciona en el dispositivo del atacante sin superar nunca el inicio de sesión.

Even the Banks Do Not Bind the Web Session, un whitepaper de cside sobre la brecha de la sesión web vinculada al dispositivo

En este whitepaper:

Resultados de nuestro análisis de los 43 bancos de consumo más maduros en seguridad: 0/43 vinculan criptográficamente la sesión web (la capa estricta tipo DBSC).

Por qué la autenticación no es integridad de sesión, y cómo el robo de cuentas moderno elude por completo el momento del inicio de sesión.

Los tres significados de "vinculado al dispositivo" y el error de categoría que hace pasar "existe fingerprinting" por "la sesión está vinculada."

Cinco formas en que una sesión válida acaba en el dispositivo equivocado: logs de infostealers, phishing adversary-in-the-middle, reenvío por proxy residencial, navegadores anti-detección y malware en el dispositivo.

Dónde encajan las Device Bound Session Credentials (DBSC), el calendario de adopción y qué significa la brecha para los bancos y la Fortune 1000.

Consigue el whitepaper

Rellena el formulario para obtener el informe completo sobre sesiones web vinculadas al dispositivo.

Cargando el formulario…

En una sola pregunta sencilla

¿El token de autenticación de cada usuario está vinculado al dispositivo, o puede moverse a otro navegador?

Un token de autenticación es la clave que el navegador guarda en una cookie o en el almacenamiento local cuando un usuario supera la contraseña y el 2FA. Es un token bearer: quien lo tiene es tratado como ese usuario, en cualquier dispositivo. Cópialo en otro navegador y ese navegador es esa persona. En los 43 bancos que analizamos, nada en la sesión web lo impide.

El problema de fondo

Los bancos puntúan el dispositivo web. Por lo general no vinculan criptográficamente la sesión web en vivo. El momento del inicio de sesión está reforzado; la sesión que viene después, no.

El barrido bancario, en cuatro cifras

0/43 Bancos que vinculan criptográficamente el token de sesión web (DBSC)
≥88% Usan inteligencia de dispositivo web / puntuación conductual
8/43 Usan un passkey web como inicio de sesión principal
~98% Vinculan la credencial de la app móvil a hardware seguro

Hasta el grupo más avanzado deja la sesión de navegador como una cookie bearer.

Lo que los bancos ya hacen bien

Inicio de sesión y transacción

Maduro

Biometría conductual, defensa contra bots, perfilado de dispositivos, autenticación con step-up y passkeys en algunos mercados.

Canal móvil

Vinculado

~98% vincula la credencial de la app a Secure Enclave / Keystore, a menudo con atestación de app encima.

Sesión de navegador

Brecha abierta

La cookie web posterior al inicio de sesión sigue siendo un token bearer, aceptada sin prueba del dispositivo de origen.

La separación de canales es la clave. "Los bancos vinculan dispositivos" puede ser cierto para móvil y falso para sesiones de navegador al mismo tiempo.

Cinco formas en que una sesión válida acaba en el dispositivo equivocado

Logs de infostealer

El malware extrae las cookies del navegador del dispositivo de la víctima.

Phishing adversary-in-the-middle

El kit hace de proxy de los flujos de MFA / passkey y roba la sesión resultante.

Reenvío por proxy residencial

La cookie se presenta desde una ubicación de red verosímil.

Navegadores anti-detección

Los fingerprints se ajustan para evitar una discrepancia evidente.

RAT / malware en el dispositivo

El atacante opera desde el dispositivo legítimo.

La economía del atacante se ha movido a las cookies robadas y reenviadas. La defensa no se ha movido con ella.

Cierra la brecha con cside

Consigue DBSC multinavegador con cside

DBSC vincula la sesión del navegador al dispositivo, pero hoy solo en Chrome. cside extiende la protección de sesiones vinculadas al dispositivo a todos los navegadores como JavaScript de origen: detecta el replay de cookies robadas, evidencia la sesión real y frena el robo de cuentas que sobrevive al inicio de sesión. Sin cambios de DNS ni en la ruta del tráfico.

Reservar una demo