Google a commencé à rendre la technologie Device Bound Session Credentials (DBSC) disponible au public pour les utilisateurs de Windows sur le navigateur Chrome 146, après l’avoir annoncée pour la première fois en avril 2024. Elle sera étendue à macOS dans une prochaine version de Chrome. Cette technologie vise l’un des problèmes de sécurité des sessions les plus courants : le vol de cookies, qui permet aux attaquants d’accéder aux comptes sans avoir besoin des mots de passe.
Le vol de sessions se produit généralement lorsqu’un utilisateur télécharge involontairement un logiciel malveillant. Après son exécution, le logiciel peut extraire les cookies actuels du navigateur ou attendre que l’utilisateur se connecte à de nouveaux comptes, puis envoyer ces jetons à un serveur contrôlé par l’attaquant. Google indique que les familles de logiciels voleurs d’informations, telles que LummaC2, sont devenues plus sophistiquées dans la collecte des identifiants.
Le risque associé à ces cookies est accru par la durée de validité prolongée de certains d’entre eux : les attaquants peuvent les utiliser pour accéder sans autorisation aux comptes, puis les regrouper, les échanger ou les vendre entre acteurs criminels. De plus, les logiciels malveillants avancés, une fois présents sur l’appareil, peuvent lire les fichiers et la mémoire dans lesquels les navigateurs stockent les cookies d’authentification. Google estime donc qu’il n’existe aucun moyen fiable d’empêcher l’extraction des cookies en s’appuyant uniquement sur des logiciels, quel que soit le système d’exploitation.
Lier la session à une clé qui ne quitte pas l’appareil
DBSC modifie ce modèle en liant cryptographiquement la session d’authentification à un appareil précis. La technologie utilise des modules de sécurité pris en charge par le matériel, tels que le TPM sous Windows et le Secure Enclave sous macOS, pour créer une paire unique de clés publique et privée. La clé privée ne peut pas être exportée de l’appareil.
Le serveur n’émet de nouveaux cookies à courte durée de vie qu’après que Chrome a prouvé qu’il détient la clé privée associée à la session. Comme l’attaquant ne peut pas voler cette clé, les cookies extraits expirent rapidement et deviennent inutiles pour accéder aux comptes. Google affirme avoir observé une forte baisse du vol des sessions protégées par DBSC depuis le lancement d’une version préliminaire du protocole au cours de l’année dernière.
Les sites, grands ou petits, peuvent adopter des sessions liées au matériel en ajoutant à leurs systèmes dorsaux des points de terminaison dédiés à l’enregistrement et à la mise à jour, tout en conservant la compatibilité avec l’interface actuelle. Le navigateur prend en charge en arrière-plan les opérations de chiffrement complexes et la rotation des cookies, tandis que l’application web continue d’utiliser les cookies standards pour accéder à ses services.
Protéger les sessions sans suivre l’utilisateur
DBSC a été conçue dans le respect de la confidentialité. Chaque session repose sur une clé distincte, ce qui empêche les sites d’utiliser ces identifiants pour relier l’activité de l’utilisateur entre différentes sessions ou entre plusieurs sites sur un même appareil. Le protocole n’envoie pas au serveur d’identifiants de l’appareil ni de données d’attestation, à l’exception de la clé publique propre à la session, nécessaire pour prouver la possession de la clé privée.
Selon Google, cet échange limité d’informations réduit les risques d’utilisation de la technologie pour le suivi intersites ou la création d’une empreinte permettant d’identifier l’appareil.
Un standard ouvert en développement continu
DBSC a été conçue dès le départ comme un standard web ouvert dans le cadre d’un processus du W3C et avec l’adoption du groupe de travail sur la sécurité des applications web. Google a collaboré avec Microsoft à la conception du standard. De nombreuses plateformes web, dont Okta, ont également participé aux deux Origin Trials au cours de l’année dernière et ont fourni des retours fondés sur les tests et l’utilisation.
Google met à la disposition des développeurs un guide de mise en œuvre, ainsi que les spécifications du protocole, un dépôt GitHub et une page permettant de signaler des bugs ou de proposer des fonctionnalités.
Les domaines de développement à venir comprennent :
- Sécurisation de l’identité fédérée : étendre DBSC afin de prendre en charge la liaison entre différents actifs, de sorte que la session de la partie utilisatrice reste liée à la clé de l’appareil d’origine utilisée auprès du fournisseur d’identité pendant tout le processus de connexion unifiée.
- Fonctionnalités d’enregistrement avancées : lier les sessions à des éléments de clés de confiance déjà présents, tels que des certificats mTLS ou des clés de sécurité matérielles, au lieu de créer une nouvelle clé lors de la connexion.
- Prise en charge élargie des appareils : étudier l’ajout de clés fondées sur des logiciels pour protéger les appareils qui ne disposent pas de matériel de sécurité dédié.