Adieu aux cookies volés maintenant l'authentification est liée à l'appareil dans Chrome

Publié 6 min de lectura 159 lecture

Depuis des années, les agresseurs cherchent des moyens simples et lucratifs d'accéder à des comptes en ligne : au lieu de casser des mots de passe, ils volent ce qui permet déjà un accès temporaire à un service : les cookies de session. Ces jetons, s'ils sont assez longs, permettent à un intrus de saisir un compte sans avoir à connaître le mot de passe, et se retrouvent souvent sur le marché de la cybercriminalité. Pour contrer cette menace Google a décidé de lier ces sessions à la propre machine de l'utilisateur en utilisant une technologie qui commence maintenant à atteindre tous les utilisateurs Chrome sur Windows.

Titres de créance pour la session de l'appareil est la réponse de Google au problème "exfiltration de session". En termes simples, au lieu de posséder simplement un cookie assez pour entrer un compte, Chrome peut exiger du navigateur de démontrer cryptographiquement que le cookie est utilisé à partir du même périphérique qui l'a généré. Donc, si un malware obtient de copier le cookie et l'envoie à un serveur contrôlé par l'attaquant, ce cookie perd de la valeur parce qu'il ne peut pas prouver qu'il vient de l'ordinateur légitime.

Adieu aux cookies volés maintenant l'authentification est liée à l'appareil dans Chrome
Image générée avec IA.

La technique est basée sur des modules de sécurité présents dans le matériel: dans Windows le module de plate-forme de confiance (TPM) est utilisé et, sur les ordinateurs Apple, l'équivalent serait l'enclave sécurisée. Ces environnements permettent de créer des clés cryptographiques privées qui ne peuvent être exportées en dehors de l'appareil. Lorsque le serveur doit émettre ou renouveler un jeton de session, il demande Chrome pour tester la possession de cette clé privée. Chrome signe ou participe à un protocole qui démontre que la possession sans révéler la clé elle-même. Le résultat est que les cookies deviennent éphémères et liés à la machine, non transférables.

Google a commencé à tester DBSC en version bêta ouverte et annonce maintenant que la fonctionnalité est disponible pour tous les utilisateurs de Windows qui mettent à jour à Chrome 146; le support pour macOS arrivera dans une version ultérieure du navigateur. L'entreprise explique que, lorsque l'appareil n'a pas de stockage sécurisé des clés, DBSC ne brise pas le flux d'authentification : il revient simplement au comportement traditionnel pour ne pas laisser l'utilisateur sans accès. Cette transition en douceur est importante pour ne pas causer de friction dans des équipements plus anciens ou des environnements virtualisés où il n'existe pas de MPT physique.

Les drivers de fonction prétendent avoir observé une réduction significative des tentatives de vol de session à partir des premiers tests, suggérant que lier les sessions au matériel peut faire considérablement dégrader la rentabilité des entreprises pour les opérateurs de voleurs - les familles de malware qui extrait des données du système. Si vous voulez comprendre comment ces programmes malveillants fonctionnent et pourquoi ils sont si dangereux, il ya des analyses techniques accessibles par exemple dans le blog de Malharebytes sur les familles comme Vidar et d'autres menaces similaires: Malhareoctets Labs.

DBSC n'apparaît pas dans un vide : elle s'inscrit dans une tendance plus marquée à l'authentification « liée aux appareils » et à l'utilisation généralisée d'éléments matériels sécurisés. Dans cet écosystème, il existe des liens avec des normes et des technologies telles que WebAuthn et FIDO Alliance, qui cherchent à réduire la dépendance par mot de passe et apporter la vérification cryptographique à l'authentification quotidienne. Si vous souhaitez approfondir les normes d'authentification moderne, la FIDO Alliance vous propose une documentation accessible: fidoalliance.org.

Confidentialité et limites. Google a conçu l'architecture avec des critères de confidentialité clairs : la vérification se fait avec une clé par session et, selon l'entreprise, n'implique pas l'envoi d'identificateurs d'appareil ou de données d'attestation qui permettent de corréler l'activité entre les sites. En d'autres termes, l'intention est d'améliorer la sécurité sans transformer les clés de session en mécanisme de suivi. Ceci est important parce qu'une solution qui protégerait les sessions mais permettrait le profilage des utilisateurs aurait été inacceptable.

Toutefois, des contraintes pratiques doivent être prises en compte. Si un attaquant obtient le contrôle complet de l'appareil (par exemple au moyen d'une rootkit ou d'un accès physique prolongé), il peut restaurer ou manipuler des états locaux et éventuellement supprimer l'atténuation. En outre, les environnements et les machines virtualisés sans TPM physique représentent des défis : le mécanisme ne fait que désactiver et revenir au comportement traditionnel pour maintenir la convivialité. Il y a aussi des problèmes opérationnels pour les entreprises : la gestion des appareils, la migration des utilisateurs entre les machines ou les politiques de récupération d'identités peuvent nécessiter des solutions complémentaires (p. ex., des corbeilles clés ou des procédures de restauration) qui devraient être soigneusement conçues.

Au niveau institutionnel, l'arrivée de DBSC est un point intéressant pour le matériel de sécurité et les administrateurs : elle peut réduire le risque associé aux cookies volés, mais elle ne remplace pas d'autres défenses. La combinaison de plusieurs couches - mises à jour fréquentes du navigateur, authentification multifactorielle (MFA), protection des paramètres et formation de l'utilisateur sur le risque de malware - reste la stratégie la plus robuste. Pour mieux comprendre le rôle de TPM dans Windows et comment il est intégré dans la chaîne de confiance, Microsoft propose ici la documentation technique disponible: Microsoft Apprendre - TPM. Apple, pour sa part, documente son Enclave Secure sur ses pages de sécurité de développeur : Enclave sécurisée - Apple.

Adieu aux cookies volés maintenant l'authentification est liée à l'appareil dans Chrome
Image générée avec IA.

Un autre aspect positif est que Google a travaillé avec Microsoft pour rendre la conception compatible avec un objectif plus large: transformer la technique en quelque chose d'interopérable et, dans la mesure du possible, devenir un standard ouvert que d'autres navigateurs et services peuvent adopter. Cette approche collaborative accroît la probabilité que la protection ne se limite pas à un seul écosystème et, espérons-le, accroîtra la sécurité de l'ensemble du Web.

Pour l'utilisateur moyen, le conseil est direct: garder Chrome à jour (la protection vient avec les versions récentes), utiliser MFA sur tous les comptes qui le permettent et considérer les clés de sécurité physique si possible. Dans les environnements ministériels, les équipes informatiques devraient évaluer comment DBSC s'intègre dans leurs politiques de gestion des appareils et les flux de récupération des comptes. L'objectif n'est pas de remplacer les bonnes pratiques, mais de réduire une fenêtre d'exposition particulièrement rentable pour les attaquants.

Si vous voulez lire les notes officielles des mises à jour Chrome ou suivre les informations de sécurité postées par Google, les pages de publicité Chrome et le blog de sécurité Google sont de bons points de départ: Chrome sort et Google Security Blog. La combinaison de ces pièces - documentation du navigateur, informations matérielles de sécurité et analyse des menaces - aide à comprendre pourquoi lier les sessions à l'appareil peut signifier une réelle amélioration dans la lutte contre le vol de session.

Couverture

Autres

Plus de nouvelles sur le même sujet.