Unit 42 décrit trois scénarios visant Google Password Manager dans Chrome sous Windows, sur des appareils équipés d’un TPM. Ils supposent qu’un malware se trouve déjà sur l’appareil : ils ne démontrent ni une faille de toutes les passkeys ni une exploitation généralisée. Google a retiré le secret SDS des journaux de Chrome après le signalement, mais Unit 42 indique qu’il reste accessible en mémoire dans le scénario étudié.
Une attaque qui commence sur l’appareil
Les passkeys remplacent les mots de passe partagés par une paire de clés cryptographiques. La clé privée n’est normalement ni révélée au site ni saisie par l’utilisateur comme un mot de passe. Certaines passkeys sont toutefois synchronisées entre appareils par leur fournisseur, et Google a annoncé en septembre 2026 un transfert sécurisé entre gestionnaires sur Android. Cette portabilité contrôlée ne rend pas la clé équivalente à un mot de passe en clair, mais elle rappelle que le fournisseur, la synchronisation et les parcours de transfert font aussi partie du périmètre de confiance.
Dans une recherche publiée par Unit 42, trois techniques — baptisées Pass-ta-key, Silver Pass-ta-key et Golden Pass-ta-key — ciblent Google Password Manager dans Chrome sous Windows, sur des appareils équipés d’un TPM. Leur point de départ est toujours le même : un malware s’exécute déjà sur l’appareil de la victime, avec les droits d’un utilisateur ordinaire.
Ce cadre est essentiel. Il ne s’agit pas d’une attaque à distance qui casserait la cryptographie des passkeys. Il s’agit de détourner les mécanismes de confiance qui relient le navigateur, l’appareil, le gestionnaire cloud et le site auquel on se connecte.
Trois chemins de confiance mis à l’épreuve
Le premier chemin, Pass-ta-key, réutilise l’identité matérielle de l’appareil pour obtenir une assertion de connexion sans empreinte, code PIN ou interaction visible. Lorsque le service vérifie correctement le bit User Verified (UV) de WebAuthn, cette assertion devrait être refusée si une vérification utilisateur était obligatoire. Le problème apparaît lorsque le service fait confiance au paramètre de la requête sans contrôler le résultat retourné.
Le deuxième chemin, Silver Pass-ta-key, concerne la réinscription de l’appareil. Après la suppression ou l’invalidation d’un état local, Chrome peut entrer dans une phase où une nouvelle clé de vérification doit être enregistrée. La recherche décrit un scénario dans lequel une clé contrôlée par l’attaquant est inscrite pendant cette transition. Elle pourrait ensuite produire des assertions qui semblent avoir été vérifiées par l’utilisateur.
Le troisième, Golden Pass-ta-key, vise le Security Domain Secret (SDS), un secret maître de 32 octets utilisé pour déchiffrer les passkeys synchronisées. Les chercheurs expliquent qu’il peut apparaître temporairement dans la mémoire du processus Chrome lors d’une nouvelle inscription. S’il était extrait, les passkeys synchronisées pourraient être déchiffrées et réutilisées depuis l’environnement de l’attaquant.
Unit 42 indique que Google a retiré le SDS des journaux de Chrome après le signalement, mais que le secret restait accessible en mémoire dans le scénario étudié. Unit 42 précise aussi avoir signalé puis fait corriger le contrôle du bit UV chez eBay. Ces corrections ciblent des failles précises : la recherche ne dit pas que toutes les versions actuelles de Chrome ou tous les services sont vulnérables, ni que l’ensemble des chemins décrits a été corrigé. Elle souligne enfin que changer le PIN ou supprimer des données ne constitue pas nécessairement une révocation démontrée d’un secret déjà volé.
Ce que l’épisode change pour les entreprises
Une passkey réduit fortement le phishing et la réutilisation de mots de passe. Elle ne transforme pas un appareil compromis en appareil fiable. Si un malware peut lire des données locales, modifier un état de réinscription ou inspecter la mémoire d’un navigateur, il peut attaquer la chaîne autour de l’authentification.
Les responsabilités sont donc partagées :
- Les services doivent exiger
userVerification: requiredquand le niveau de risque le justifie et vérifier le bit UV dans chaque réponse WebAuthn. - Les gestionnaires d’identifiants doivent protéger les parcours de récupération et de réinscription, valider l’origine des nouvelles clés et éviter d’exposer des secrets maîtres dans les logs ou la mémoire client.
- Les entreprises doivent réduire le risque sur les endpoints : mises à jour, protection contre les malwares, droits minimaux, surveillance des changements inhabituels et procédure de révocation testée.
Pour une TPE-PME, le réflexe est concret : une demande inattendue de récupération, un nouvel appareil enregistré ou un comportement inhabituel du navigateur doit déclencher une vérification, pas une validation automatique.
Passkeys et mots de passe ne s’opposent pas
Cette recherche ne justifie pas un retour aux mots de passe partout. Elle rappelle plutôt qu’aucune méthode d’authentification ne doit être évaluée isolément. Les passkeys sont pertinentes pour les services qui les prennent en charge ; des mots de passe uniques restent nécessaires pour les comptes et systèmes qui ne les acceptent pas encore.
Pour replacer cette recherche dans l’évolution plus large de l’authentification sans mot de passe, lisez aussi notre article sur les changements réels apportés par l’authentification sans mot de passe.
Le lien avec Soclyde
Soclyde complète les passkeys pour les comptes qui utilisent encore un mot de passe : le produit aide à créer des secrets uniques et à les conserver dans un coffre chiffré local-first. Il ne protège pas un appareil infecté et ne remplace ni les passkeys, ni la MFA, ni la supervision des postes.
À retenir
Pass-ta-key vise une chaîne précise — Google Password Manager, Chrome sous Windows, un TPM et un appareil déjà compromis — et non la cryptographie de toutes les passkeys. Pour approfondir les risques liés aux logiciels malveillants sur les postes, lisez notre guide pratique sur les infostealers et notre analyse d’un infostealer qui contourne le chiffrement des données de Chrome.
