Pass-ta-key : ce que l’attaque contre les passkeys Google signifie vraiment

Les passkeys seraient-elles finalement peu sûres ? C’est précisément la question que soulève Pass-ta-key.

Palo Alto Networks Unit 42 décrit trois chaînes d’attaque permettant à un malware d’abuser de passkeys synchronisées par Google, de contourner la vérification de l’utilisateur et, dans le scénario le plus grave, d’extraire toutes les clés privées de passkeys d’un compte.

Aucune ne casse WebAuthn, FIDO2 ou la cryptographie à clé publique. Toutes supposent qu’un malware s’exécute déjà sur le PC Windows de la victime. C’est une contrainte importante. Mais dire que « tout est déjà perdu sur un endpoint compromis » serait trop facile : Golden Pass-ta-key vise à transformer une intrusion locale en un ensemble exportable et durable de toutes les passkeys synchronisées, bien au-delà du vol d’une seule session.

L’évaluation en bref

Oui, c’est un sujet de sécurité nouveau et autonome. Ce n’est toutefois pas une raison d’abandonner les passkeys ou de revenir exclusivement aux mots de passe.

• Le protocole tient : Origin Binding, challenge-response et cryptographie asymétrique ne sont pas cassés.
• Une implémentation précise est attaquée : Google Password Manager, Chrome, Windows et un TPM dans la configuration étudiée par Unit 42.
• L’endpoint doit déjà être compromis : un site quelconque ne peut pas lancer cette attaque depuis Internet contre une machine saine.
• L’impact potentiel reste considérable : d’une assertion de connexion créée silencieusement jusqu’à l’extraction de toutes les clés privées synchronisées.
• Passkeys synchronisées et liées à un appareil n’ont pas le même profil de risque : ce sont deux passkeys, mais pas le même niveau d’assurance.
• Les mots de passe restent une moins bonne solution : ils peuvent aussi être hameçonnés, réutilisés, devinés ou volés dans une base serveur.

Mon évaluation est donc la suivante : portée technique étroite et prérequis exigeant, mais impact potentiellement très élevé en cas de réussite.

Périmètre technique et éléments probants

Au 31 août 2026, l’analyse repose sur les chaînes documentées par Unit 42, la spécification WebAuthn, la documentation Google, l’issue Chromium public et les exigences NIST pour les authentificateurs synchronisables. Pass-the-Passkey de SpecterOps, CVE-2026-34348, le downgrade FIDO de Proofpoint ainsi que les travaux d’Expel et SquareX complètent ce tableau.

Publiée le 3 août puis actualisée le 14 août, la recherche vise explicitement Google Password Manager dans Chrome sous Windows, sur des appareils équipés d’un Trusted Platform Module. Des questions comparables peuvent exister ailleurs, mais ces trois attaques n’ont pas été démontrées sur d’autres navigateurs, systèmes ou fournisseurs.

Aucune campagne active exploitant ces techniques précises n’est documentée. Nous avons des recherches, des Proofs of Concept et du Responsible Disclosure. Une démonstration technique ne signifie pas une exploitation massive.

Ce que protège réellement une passkey

Une passkey n’est pas un mot de passe très long. C’est un identifiant WebAuthn fondé sur la cryptographie asymétrique.

private key -> remains with the authenticator
public key  -> is registered with the online service

La Relying Party conserve la clé publique, une Credential ID et le compte. Lors de la connexion, elle envoie un challenge aléatoire inédit. L’authentificateur signe des données liant notamment ce challenge au contexte du site appelant, puis le serveur vérifie la signature.

La clé privée n’est pas transmise comme un mot de passe. Une fuite côté service ne livre idéalement que des clés publiques, inutilisables pour produire des signatures. La liaison à la Relying Party ID et à l’origine web empêche aussi une passkey de example.com de produire sur un domaine ressemblant une assertion valable pour example.com. Aucun secret ne peut être saisi sur le mauvais site ou dicté au téléphone.

C’est le sens précis de résistant au phishing. Selon NIST, un vérificateur frauduleux ne doit obtenir ni le secret d’authentification ni une réponse réutilisable auprès du service légitime. WebAuthn l’assure par une liaison cryptographique au nom du vérificateur. Pass-ta-key ne change pas cette propriété : le malware se trouve déjà sur l’appareil de confiance.

User Presence et User Verification ne sont pas synonymes

• User Presence, UP : l’utilisateur a effectué une action de présence, par exemple toucher une clé ou confirmer une boîte de dialogue.
• User Verification, UV : l’authentificateur l’a vérifié localement via Windows Hello, un PIN ou la biométrie.

L’assertion contient ces résultats dans les flags d’authenticatorData. Si le serveur demande userVerification: "required", il doit aussi vérifier le flag UV reçu. Unit 42 n’a pas pu terminer l’attaque simple contre GitHub faute d’UV. Chez eBay, la connexion avait d’abord réussi malgré cette exigence, avant correction de la validation serveur.

Une signature correcte ne suffit donc pas toujours à une MFA correctement implémentée. La Relying Party doit valider les conditions réellement confirmées par l’authentificateur.

Pourquoi la synchronisation élargit le domaine de confiance

Une passkey liée à un appareil reste sur un authentificateur précis. Une passkey synchronisée doit être chiffrée, transportée et restaurée sur d’autres appareils autorisés.

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

Chaque couche exige des règles de confiance, onboarding, récupération, chiffrement et révocation. NIST classe donc séparément les authentificateurs synchronisables : ils peuvent convenir jusqu’à Authentication Assurance Level 2, tandis qu’AAL3 exige des clés non exportables protégées matériellement ou un authentificateur distinct. Les passkeys synchronisées ne sont pas faibles, mais leur confort crée un autre modèle d’assurance. Pass-ta-key vise précisément ce domaine supplémentaire.

Le périmètre exact de la recherche

Les conditions sont les suivantes : Google Password Manager gère les passkeys, Chrome fonctionne sous Windows, l’appareil possède un TPM, le malware s’exécute déjà comme l’utilisateur, l’environnement Google est configuré et certaines variantes exigent de lire des données Chrome, modifier des états ou inspecter sa mémoire.

Il ne s’agit ni d’une attaque universelle contre toute passkey ni d’une extraction distante d’une clé WebAuthn depuis le TPM. La formulation exacte est : Unit 42 a démontré trois chaînes visant confiance, onboarding et récupération des passkeys Google synchronisées sur des endpoints Windows compromis.

Phase zéro : la cartographie locale des passkeys

Le malware lit d’abord la base de synchronisation Chrome. Ses enregistrements WebauthnCredentialSpecifics contiennent Relying Parties, utilisateurs, Credential IDs et clés privées chiffrées.

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

L’accès n’exigeait pas de privilèges élevés pendant le test. Les clés ne sont pas en clair, mais les métadonnées révèlent les services, comptes et Credential IDs à cibler. Un infostealer peut donc inventorier puis sélectionner les comptes les plus précieux.

Pass-ta-key : une assertion valide sans action de l’utilisateur

La première variante détourne l’Identity Key avec laquelle Chrome prouve l’identité de l’appareil à Google Cloud Authenticator. Chrome l’adosse au TPM et exporte la clé privée via Windows CNG sous forme de NCRYPT_OPAQUE_KEY_BLOB, réutilisable cryptographiquement sur le même TPM.

Cette protection ne résout pas l’autorisation. Un malware exécuté comme l’utilisateur pouvait lire wrapped_identity_private_key ou le récupérer en mémoire, puis appeler Windows CNG. Le TPM signe parce que la demande vient techniquement du bon appareil, sans savoir si Chrome ou un malware appelle l’API.

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

Le malware emploie ainsi l’appareil et le cloud comme service de signature, sans forcément exporter la passkey. Le flag UV reste la limite : l’Identity Key prouve la possession de l’appareil, pas le PIN ou la biométrie. Un service exigeant et contrôlant UV doit refuser UV = 0. Mais de nombreux services utilisent preferred ou vérifient mal la réponse, réduisant alors la connexion à l’accès à l’identité de l’appareil.

Silver Pass-ta-key : l’attaquant enregistre sa propre identité UV

Silver contourne cette limite sans casser Windows Hello. Le malware fait oublier l’état de l’appareil ou supprime passkey_enclave_state, ce qui force un re-onboarding. Sous Windows, Chrome peut d’abord utiliser le PIN de récupération de Google Password Manager et créer l’état uv_key_pending, avant de générer la véritable UV Key lors de l’utilisation suivante.

La victime doit saisir son PIN GPM dans ce processus inattendu, mais le malware n’a pas besoin de le voler. L’attaquant génère alors sa propre paire et transmet sa clé publique comme nouvelle UV Key. Selon Unit 42, Cloud Authenticator ne vérifiait pas son origine matérielle de confiance et l’associait à l’identité légitime de l’appareil.

L’attaquant peut ensuite signer lui-même. Cloud Authenticator interprète cela comme une vérification locale et produit des assertions avec UV, même si le PC victime est hors ligne. L’issue Chromium « GPM Passkeys Are Vulnerable to User Verification Key Abuse » était marqué WAI lors de ma vérification. La leçon demeure : l’onboarding ou la récupération qui lie une nouvelle clé de confiance est un événement d’authentification critique.

Golden Pass-ta-key : le cloud devient une source de clés exportables

La variante la plus grave vise le Security Domain Secret ou SDS, un secret de 32 octets protégeant les clés privées synchronisées d’un compte Google Password Manager. Le client ne devrait posséder qu’un wrapped_secret, déchiffré par Cloud Authenticator avec une clé propre à l’appareil.

Mais onboarding et récupération doivent réintégrer des appareils dans la Security Domain. Unit 42 a constaté que Chrome reçoit alors le SDS sous une forme accessible au client. Il apparaissait même initialement dans le log FIDO de Chrome. Google a supprimé ce log, mais le SDS passe encore par la mémoire du processus durant l’opération.

Le malware doit donc provoquer ce parcours puis extraire la mémoire au bon moment :

1. Il force un nouvel onboarding.
2. Il attend la création ou modification de l’état local de l’enclave.
3. Il lit la mémoire Chrome et recherche le SDS.
4. Il l’associe aux données de synchronisation déjà lues.
5. Il déchiffre les clés privées.
6. Un authentificateur indépendant de l’appareil victime peut produire des assertions valides.

Contrairement à un cookie révocable ou expirant, Golden vise toutes les clés déjà synchronisées. Unit 42 indique aussi que le même SDS protège les futures passkeys et qu’aucune rotation ou révocation visible n’existait dans l’architecture étudiée. Cela ne prouve ni que tous les fournisseurs fonctionnent ainsi ni que Google ne puisse modifier son architecture.

Pourquoi un malware local ne rend pas l’attaque anodine

Un malware local peut déjà voler des sessions, lire le navigateur, manipuler des transactions, exfiltrer des fichiers ou agir dans le compte. Aucun mécanisme ne peut faire entièrement confiance à un client compromis. Le vol de secrets depuis un navigateur ou gestionnaire fait depuis longtemps partie des infostealers.

La recherche apporte néanmoins des faits nouveaux : un processus non privilégié utilisait une clé Chrome liée au TPM ; la frontière appareil/utilisateur dépendait du flag UV ; le re-onboarding autorisait une clé UV hostile ; le secret central apparaissait dans un log puis en mémoire ; le chemin le plus grave rendait des clés utilisables hors appareil ; et le compteur de signature est souvent peu fiable avec des credentials synchronisés partagés entre appareils.

« Endpoint compromis » est un prérequis, pas une description de l’impact. En Incident Response, une session temporaire et des clés privées durables pour plusieurs services sont deux situations très différentes.

Pass-ta-key n’est qu’une partie de la nouvelle surface d’attaque

Les recherches de 2025 et 2026 décrivent plusieurs chemins sans rupture mathématique : Pass-ta-key abuse de la synchronisation et de la récupération après infection ; Pass-the-Passkey combine une assertion journalisée à une faille de replay serveur ; le downgrade FIDO exploite un fallback hameçonnable ; Passkeys Pwned exige une extension ou un script hostile ; les infostealers volent la session déjà authentifiée.

Tous visent une couche de confiance autour de WebAuthn, pas la cryptographie : récupération, validation serveur, navigateur ou session. Une rupture du protocole remettrait en cause toutes les implémentations. Ici, chaque chemin exige sa propre défense.

Pass-the-Passkey : réutiliser une assertion valide

Pour Black Hat USA 2026, SpecterOps a identifié trois vulnérabilités dans Windows 11 et Microsoft Entra ID et plus de 20 techniques. Windows journalisait des assertions WebAuthn complètes dans Microsoft-Windows-WebAuthN/Operational, notamment Credential ID, challenge, données d’authentificateur et signature. Entra ID les acceptait à nouveau pendant une courte fenêtre.

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

CVE-2026-34348 désigne la partie Windows. Le 14 juillet 2026, Microsoft a réduit la signature journalisée à quelques octets et supprimé la source du replay. Des compteurs ont aussi été contrôlés pour certaines clés FIDO2, mais des credentials de plateforme ou synchronisés renvoient zéro ou partagent un état.

Les assertions n’ont pas leur place dans les logs. Les challenges doivent être aléatoires, courts, uniques et liés à la session. Une autre technique exploite le Parent-Window-Handle de l’API Windows : un processus local peut faire paraître une vraie boîte Passkey comme appartenant au navigateur ou au mail. Toute demande inattendue doit donc être traitée comme une notification MFA push inattendue.

Le fallback le plus faible fixe le niveau réel

Proofpoint a démontré en 2025 un downgrade FIDO contre Entra ID. Un flux Evilginx modifié prétendait utiliser un navigateur incompatible FIDO. La plateforme proposait alors SMS, OTP ou une méthode hameçonnable, permettant au flux Adversary-in-the-Middle de voler identifiants et session.

Origin Binding n’est pas contourné : la cérémonie WebAuthn n’a jamais lieu. Cela suppose une méthode plus faible autorisée et aucune exploitation réelle n’est documentée. Une politique n’est résistante au phishing que si login, récupération et helpdesk n’acceptent aucun chemin hameçonnable pour le niveau concerné.

Le navigateur appartient au modèle de sécurité

Avec Passkeys Pwned, SquareX montre qu’une extension malveillante ou un script dans le navigateur peut influencer navigator.credentials.create() et navigator.credentials.get(). Lors de l’enregistrement, l’utilisateur peut voir une vraie validation biométrique alors qu’un credential contrôlé par l’attaquant est lié.

Ce travail d’un fournisseur n’est pas un exploit universel. L’extension ou le script doit déjà intervenir dans le chemin WebAuthn. Mais extensions, Content Scripts et proxies WebAuthn appartiennent bien à la Trusted Computing Base. Allowlist et contrôle des API privilégiées sont donc aussi des mesures d’identité.

Les passkeys protègent la connexion, pas automatiquement la session

Après authentification, le service utilise souvent un cookie ou token. Si un infostealer le vole et que le serveur l’accepte ailleurs, l’attaquant n’a besoin ni du mot de passe ni de la passkey. C’est aujourd’hui un chemin plus pratique que beaucoup de Proofs of Concept.

Il faut donc stockage sûr, durée adaptée au risque, réauthentification, révocation et, si possible, liaison cryptographique au dispositif. Dire que « MFA a été contournée » est trompeur : MFA a réussi, son résultat a ensuite été volé.

PoisonSeed montre comment naît le battage médiatique

En juillet 2025, Expel a d’abord annoncé qu’un QR code légitime relayé via phishing permettait de détourner la Cross-Device Authentication. Quelques jours plus tard, l’entreprise a retiré cette affirmation et présenté ses excuses.

Le contrôle de proximité locale n’avait pas été vaincu : sans proximité, le flux expirait, tous les défis MFA échouaient et aucun accès n’était obtenu. Une bonne communication distingue prise de compte observée, Proof of Concept reproductible, hypothèse théorique et hypothèse réfutée.

Mon évaluation de sécurité

La portée est limitée à Google Password Manager dans Chrome sous Windows avec TPM. La probabilité est moyenne à faible, car le malware doit déjà s’exécuter et manipuler états ou mémoire. L’impact peut être élevé à très élevé : prise de compte, accès distant durable ou extraction de plusieurs clés. Le risque protocolaire reste faible.

Pour un utilisateur ordinaire, une passkey synchronisée demeure généralement plus sûre qu’un mot de passe avec SMS ou TOTP, car elle élimine de nombreux chemins de phishing, Credential Stuffing et vol de mots de passe. Pour les administrateurs, validations financières, production ou systèmes régulés, une clé de plateforme liée à l’appareil ou une clé FIDO2 séparée peut fournir la frontière adaptée. C’est une architecture graduée, pas un rejet de la synchronisation.

Ce que doivent vérifier les services web

Les serveurs devraient :

• exiger userVerification: "required" lorsque nécessaire et contrôler UV dans authenticatorData,
• valider challenge, Origin, Relying Party ID et signature,
• rendre chaque challenge aléatoire, bref, unique et lié à la session,
• exclure des logs assertions, signatures et artefacts réutilisables,
• journaliser inscription, suppression et récupération comme événements à haut risque,
• imposer une nouvelle authentification forte avant d’ajouter un authentificateur privilégié,
• collecter si possible origine et propriétés de l’authentificateur,
• évaluer attestation et authentificateurs gérés pour les cas sensibles,
• détecter changements d’appareil, géolocalisation et nouvelles liaisons,
• révoquer les sessions après un changement risqué et réauthentifier les actions critiques,
• lier les sessions à l’appareil lorsque le support est fiable.

Une bibliothèque WebAuthn reconnue réduit les erreurs, mais sa configuration reste à vérifier. eBay montre l’effet d’un flag ignoré ; Pass-the-Passkey, celui d’une mauvaise liaison entre challenge et session.

Ce que les entreprises doivent changer

Un projet passkey est à la fois IAM, endpoint, navigateur et récupération. Les comptes ordinaires peuvent utiliser la synchronisation sur appareils gérés avec protection endpoint et Conditional Access. Les comptes sensibles devraient employer des authentificateurs gérés ou une synchronisation restreinte. Administrateurs, Break Glass et comptes de grande valeur devraient disposer de clés FIDO2 liées à un appareil, d’une récupération strictement contrôlée et d’aucune synchronisation cloud incontrôlée.

Il faut aussi maintenir Chrome et Windows à jour, vérifier CVE-2026-34348, encadrer le stockage intégré par Enterprise Policies, appliquer des allowlists d’extensions, surveiller les proxies WebAuthn, étendre EDR et Application Control aux processus utilisateur, détecter l’accès aux bases de synchronisation et dumps Chrome, enquêter sur passkey_enclave_state, traiter les demandes PIN de récupération inattendues comme alertes, tester perte et récupération, supprimer les fallbacks hameçonnables, surveiller prompts et nouveaux credentials, et inventorier credentials synchronisés ou liés à un appareil.

Endpoint Detection fait directement partie du modèle d’authentification lorsque l’authentificateur vit dans le navigateur et le client.

Ce que les utilisateurs doivent faire

Il n’y a aucune raison de supprimer préventivement les passkeys. Il faut mettre à jour Chrome et Windows, limiter logiciels et extensions aux sources de confiance, conserver Windows Hello et l’antimalware, refuser les demandes inattendues, contrôler appareils et passkeys, envisager une clé physique pour les comptes précieux, puis isoler tout endpoint suspect.

En présence de malware, d’états Chrome manipulés ou d’un dump mémoire, un changement de mot de passe ne suffit pas. Il faut reconstruire ou nettoyer l’endpoint, révoquer les sessions, vérifier la récupération, supprimer les passkeys inconnues et réenregistrer des authentificateurs fiables.

Pour Golden, aucune rotation SDS simple pour l’utilisateur n’est documentée. Ne promettons pas qu’un changement de PIN ou d’une seule passkey résout tout. Après nettoyage, j’enregistrerais de nouveaux credentials liés à l’appareil, supprimerais les anciens synchronisés et associerais le fournisseur ou l’équipe Incident Response.

La véritable leçon

Les passkeys ne protègent pas de toute compromission. Elles résolvent un immense problème : ne plus donner de secret réutilisable à un serveur ou à un faux site. Leur synchronisation ajoute cependant chiffrement, confiance d’appareil et récupération, où des erreurs restent possibles même si WebAuthn est correct.

Les déclarer en échec serait faux, tout comme banaliser toute attaque après infection. Il faut continuer leur déploiement avec des promesses précises : synchronisées, elles excellent contre le phishing ; liées à du matériel, elles offrent une frontière plus forte aux comptes de valeur ; aucune ne remplace un endpoint sain, une récupération maîtrisée et une validation serveur correcte.

Les passkeys ont bien mieux verrouillé la porte contre le phishing. Pass-ta-key rappelle qu’un attaquant déjà dans la maison exige une autre défense.

À la prochaine,
Joe

FAQ