Les connexions bancaires sont durcies. Les sessions, pas encore.
Les banques comptent parmi les plateformes grand public les plus ciblées par le phishing et les plus matures en sécurité du web. Nous avons testé les 43 banques grand public les plus matures en sécurité aux États-Unis, au Royaume-Uni, dans la zone euro, au Canada, en Australie et dans les pays nordiques. Aucune ne lie cryptographiquement la session de navigateur en cours à l'appareil qui l'a créée.
Ces banques déploient déjà une forte intelligence d'appareil : biométrie comportementale, défense anti-bots, profilage d'appareil, attestation de l'application mobile. Mais évaluer un appareil n'est pas la même chose que lier la session. Le cookie post-connexion reste un token bearer : quiconque le détient est traité comme l'utilisateur. Une session volée par phishing, par un infostealer ou par un kit adversary-in-the-middle fonctionne sur l'appareil de l'attaquant sans jamais franchir la connexion.
Dans ce livre blanc :
Les résultats de notre test des 43 banques grand public les plus matures en sécurité : 0/43 lient cryptographiquement la session web (la couche stricte de type DBSC).
Pourquoi l'authentification n'est pas l'intégrité de session, et comment la prise de contrôle de compte moderne contourne entièrement le moment de la connexion.
Les trois sens de « lié à l'appareil », et l'erreur de catégorie qui fait passer « le fingerprinting existe » pour « la session est liée ».
Cinq façons dont une session valide se retrouve sur le mauvais appareil : logs d'infostealer, phishing adversary-in-the-middle, rejeu via proxy résidentiel, navigateurs anti-détection et malware sur l'appareil.
Où s'insèrent les Device Bound Session Credentials (DBSC), le calendrier d'adoption et ce que l'écart signifie pour les banques et le Fortune 1000.
Obtenir le livre blanc
Remplissez le formulaire pour recevoir le rapport complet sur les sessions web liées à l'appareil.
Cookies fonctionnels requis
Ce formulaire nécessite des cookies fonctionnels pour se charger. Modifiez vos préférences de cookies pour continuer.
Ouvrir le formulaire dans un nouvel ongletLe formulaire ne s'est pas chargé
Votre navigateur bloque peut-être le formulaire intégré. Essayez d'actualiser la page.
Ouvrir le formulaire dans un nouvel ongletEn une seule question simple
Le token d'authentification de chaque utilisateur est-il lié à l'appareil, ou peut-il passer sur un autre navigateur ?
Un token d'authentification est la clé que le navigateur stocke dans un cookie ou le stockage local une fois qu'un utilisateur a passé le mot de passe et la 2FA. C'est un token bearer : quiconque le détient est traité comme cet utilisateur, sur n'importe quel appareil. Copiez-le dans un autre navigateur et ce navigateur, c'est lui. Pour les 43 banques que nous avons testées, rien dans la session web ne l'en empêche.
Le problème de fond
Les banques évaluent l'appareil web. En général, elles ne lient pas cryptographiquement la session web en cours. Le moment de la connexion est durci ; la session qui suit ne l'est pas.
Le balayage bancaire, en quatre chiffres
Même le groupe le plus avancé laisse la session de navigateur sous forme de cookie bearer.
Ce que les banques font déjà bien
Connexion & transaction
MatureBiométrie comportementale, défense anti-bots, profilage d'appareil, authentification step-up et passkeys sur certains marchés.
Canal mobile
Lié~98 % lient les identifiants de l'app à Secure Enclave / Keystore, souvent avec une attestation d'app par-dessus.
Session de navigateur
Écart ouvertLe cookie web post-connexion reste un token bearer, accepté sans preuve de l'appareil d'origine.
La séparation des canaux est le nœud du problème. « Les banques lient les appareils » peut être vrai pour le mobile et faux pour les sessions de navigateur en même temps.
Cinq façons dont une session valide se retrouve sur le mauvais appareil
Logs d'infostealer
Le malware récupère les cookies du navigateur sur l'appareil de la victime.
Phishing adversary-in-the-middle
Le kit relaie les flux MFA / passkey et vole la session obtenue.
Rejeu via proxy résidentiel
Le cookie est présenté depuis un emplacement réseau plausible.
Navigateurs anti-détection
Les fingerprints sont ajustés pour éviter une incohérence évidente.
RAT / malware sur l'appareil
L'attaquant opère depuis l'appareil légitime.
L'économie des attaquants est passée aux cookies volés et relayés. La défense n'a pas suivi.
Obtenez un DBSC multi-navigateurs avec cside
DBSC lie la session du navigateur à l'appareil, mais aujourd'hui uniquement dans Chrome. cside étend la protection des sessions liées à l'appareil à tous les navigateurs en JavaScript first-party : détectez le rejeu de cookies volés, prouvez la session réelle et stoppez la prise de contrôle de compte qui survit à la connexion. Sans changement de DNS ni de routage du trafic.