Un chercheur de l’Unit 42 de Palo Alto Networks a publié un compte rendu détaillé de trois attaques permettant à un logiciel malveillant de prendre le contrôle de comptes protégés par des passkeys stockées dans Google Password Manager. Ces travaux sont connus sous le nom de Pass-ta-key, un nom qui fusionne passkey et l’expression pass the key, avec, en prime, une assiette de pâtes pour faire bonne mesure. Arie Olshtein, le chercheur à l’origine du rapport, a présenté ces résultats comme une nouvelle surface d’attaque pour l’authentification sans mot de passe. Les réactions des autres professionnels de la sécurité ont été plus mesurées : la technique exige que le logiciel malveillant soit déjà actif sur la machine de la victime, ce qui signifie que le modèle de sécurité des passkeys n’a jamais été conçu pour y survivre.
Les attaques visent les passkeys synchronisées de Google Password Manager dans Chrome sous Windows, où le système d’exploitation fonctionne avec un module de plateforme de confiance (TPM). Dans la variante la plus simple, le logiciel malveillant extrait une clé d’identité adossée au matériel d’un fichier que Chrome conserve sur le disque et l’utilise pour signer silencieusement des requêtes d’authentification. Aucune empreinte digitale, aucun code PIN, aucune invite à l’écran n’intervient. La variante la plus puissante, Golden Pass-ta-key, récupère le secret du domaine de sécurité de Google, la clé maîtresse qui protège chaque passkey synchronisée, et déchiffre l’ensemble de la collection sous une forme partageable qui fonctionne sur n’importe quel appareil.
La raison pour laquelle ces attaques sont possibles est propre à Windows. Selon les spécifications FIDO 2 et WebAuthn, les passkeys n’ont pas à résider dans un matériel de sécurité dédié tel qu’un TPM ou une enclave sécurisée. Sur macOS, iOS et Android, les passkeys sont stockées localement sur l’appareil, où le sandboxing des applications tient le logiciel malveillant à distance des clés privées. Windows fait exception : les applications s’exécutent généralement avec les privilèges de l’utilisateur connecté, et son sandboxing ne protège les applications que dans un seul sens. C’est pourquoi Google Password Manager et des applications tierces, dont 1Password et Dashlane, conservent les passkeys Windows dans des coffres hébergés dans le cloud et protégés par un chiffrement de bout en bout, plutôt que sur la machine elle-même. Cette conception tient les clés hors de portée des logiciels malveillants locaux, mais crée une nouvelle relation de confiance côté serveur à attaquer. Microsoft reste presque seul à proposer un stockage des passkeys basé sur le TPM, principalement pour les clients entreprises.
Le rapport d’Olshtein documente les mécanismes en détail. Chrome conserve un index des identifiants de passkeys synchronisées de l’utilisateur dans un fichier de base de données local dont la lecture ne requiert aucun privilège élevé, révélant sur quels sites l’utilisateur a enregistré des passkeys et où sont stockées les clés privées chiffrées. Pour l’attaque Pass-ta-key de base, le logiciel malveillant copie une clé d’identité encapsulée depuis le fichier d’état des passkeys de Chrome, puis utilise les API cryptographiques standard de Windows pour signer des requêtes de la même manière que Chrome le ferait lui-même. La requête signée est envoyée à l’authentificateur cloud de Google, qui la traite comme provenant d’un appareil de confiance et renvoie une assertion de connexion valide.
Que cette assertion soit acceptée par le site auquel on se connecte dépend d’un seul bit dans les données d’authentification, l’indicateur de vérification de l’utilisateur. Lorsqu’une requête est signée avec la clé de vérification, l’indicateur est activé ; lorsqu’elle est signée avec la seule clé d’identité, il ne l’est pas. Les services qui exigent la vérification de l’utilisateur et valident effectivement l’indicateur, comme GitHub, ont rejeté l’attaque lors des tests d’Unit 42. eBay l’a acceptée malgré cette exigence, parce qu’il ne validait pas l’indicateur à l’époque ; l’entreprise a corrigé la faille après la divulgation. Une seconde attaque, Silver Pass-ta-key, abuse du flux de ré-enrôlement de l’appareil pour enregistrer une clé de vérification contrôlée par l’attaquant, ce qui permet des connexions depuis une machine que la victime n’a jamais touchée.
L’argument plus large des critiques de cette présentation en nouvelle surface d’attaque est que les enjeux sont les mêmes que pour tout autre identifiant sur une machine compromise. Une fois qu’un appareil est infecté et connecté à des comptes sensibles, un attaquant peut généralement atteindre les mots de passe, les cookies de session et tout le reste auquel le compte donne accès. Les passkeys sont conçues pour stopper le hameçonnage et le vol d’identifiants depuis les serveurs, pas pour résister à un appareil entièrement compromis. La recherche a néanmoins une valeur pratique : elle montre que certains services traitent l’indicateur de vérification de l’utilisateur comme la preuve d’un véritable événement biométrique ou de saisie de code PIN, et elle donne à Google et aux autres éditeurs une liste de contrôle concrète pour durcir l’enregistrement des appareils, la récupération et la vérification côté serveur.
Pour les utilisateurs, l’enseignement ne change pas. Les passkeys neutralisent toujours les attaques les plus courantes contre les mots de passe, les sites de hameçonnage et le credential stuffing avec des mots de passe réutilisés. Garder Windows à jour et sa protection anti-malware à jour reste la défense efficace, car chaque attaque commence par un logiciel malveillant déjà actif sur la machine.
Traduit par Lydie
Sources: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (Unit 42, Aug 2026); New Pass-ta-key attack reveals all the things we didn’t know about passkeys (Ars Technica, Aug 2026); Google’s synchronized passkeys can be stolen in ‘Pass-ta-key’ attacks (Malwarebytes, Aug 2026); Pass-ta-key Research Exposes Gaps in Google’s Passkey Security on Windows (BetaNews, Aug 2026)