Les passkeys sont-elles sûres ? Ce que les attaques Pass-ta-key ont réellement cassé (août 2026)

Divulgation d'affiliation - cet article contient un lien affilié vers un gestionnaire de mots de passe. Si vous souscrivez via ce lien, nous touchons une commission sans surcoût pour vous. Cela ne change rien à ce qui suit : les constats ci-dessous proviennent de Palo Alto Networks Unit 42 et de la presse technique, et sont attribués source par source.

Réponse courte : oui, les passkeys restent sûres à utiliser, et les chercheurs qui ont publié l'attaque le disent en toutes lettres. Le 3 août 2026, Unit 42 de Palo Alto Networks a montré qu'un malware déjà en cours d'exécution sur un PC Windows peut détourner les passkeys synchronisées via Google Password Manager. Leur propre phrase est celle à retenir : « These attacks do not break the underlying cryptography. » (« ces attaques ne cassent pas la cryptographie sous-jacente »). Ce qu'ils ont cassé, c'est la plomberie autour de la passkey, pas la passkey.

Cette distinction est toute l'histoire, et la plupart des titres l'ont laissée tomber.

Ce qui a réellement été publié

Arie Olshtein, chercheur chez Unit 42, a publié « Pass the Passkey: A Novel Attack Surface in Passwordless Authentication » le 3 août 2026. C'est un billet de recherche technique, pas un article évalué par des pairs, et il vient d'un éditeur de sécurité commercial, cela mérite d'être dit franchement, car il est détaillé et crédible mais ce n'est pas un tiers neutre.

Il décrit trois techniques, appelées collectivement les attaques Pass-ta-key.

Pass-ta-key, le malware récupère sur le disque ou en mémoire la clé privée d'identité d'appareil chiffrée, puis appelle les API Windows CNG (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) pour faire signer le TPM à sa place. Il signe le hash du handshake WebSocket et se fait passer pour une installation légitime de Chrome auprès de l'authentificateur cloud de Google. Aucun déverrouillage d'appareil, aucune interaction utilisateur, aucune élévation de privilèges. Notez la subtilité : la clé ne quitte jamais le TPM, le TPM est simplement mis au travail pour l'attaquant.

Silver Pass-ta-key, le malware supprime passkey_enclave_state pour forcer un ré-enrôlement de l'appareil, exploite l'état transitoire uv_key_pending, et enregistre sa propre clé de vérification utilisateur. La faille est précise : l'authentificateur cloud ne valide pas l'attestation des clés UV nouvellement enregistrées, donc il ne peut pas savoir si elles proviennent de matériel sécurisé. Résultat : un accès réutilisable depuis une autre machine, sans l'appareil de la victime.

Golden Pass-ta-key, la pire des trois. Le Security Domain Secret, une clé maîtresse de 32 octets qui protège toutes les passkeys synchronisées, est extrait de la mémoire du processus Chrome pendant le ré-enrôlement. Avec elle, un attaquant déchiffre les enregistrements d'identifiants stockés et repart avec toutes les passkeys synchronisées du compte.

Les deux faits qui rendent la chose sérieuse

Google a retiré le Security Domain Secret des journaux de diagnostic de Chrome après la divulgation. Mais Unit 42 indique que le secret est toujours envoyé au client et reste accessible dans la mémoire du processus Chrome, reconnu, pas corrigé.

Et il n'existe aucun moyen de faire tourner ou de révoquer cette clé maîtresse dans l'implémentation actuelle. Les passkeys présentes et futures restent protégées par le même secret. C'est le point le plus dur de cette affaire, et celui qui n'a aucun contournement côté utilisateur.

La condition unique qui change tout

Chacune de ces techniques suppose un malware déjà en cours d'exécution sur la machine. Les chercheurs le disent : « malware already existing on the victim's device during the initial stage. » (« un malware déjà présent sur l'appareil de la victime lors de l'étape initiale »).

Frank Dickson, d'IDC, en a donné la formulation la plus claire, dans Computerworld : « This isn't passkeys getting hacked from across the internet. It's what [an attacker] does once they're already inside the house. » (« il ne s'agit pas de passkeys piratées depuis l'autre bout d'Internet. C'est ce que fait [un attaquant] une fois qu'il est déjà dans la maison »).

Le périmètre est donc étroit et précis :

Aucun phishing n'est nécessaire, aucune extension malveillante, aucune session volée, aucun repli forcé vers un autre facteur. Et aucune exploitation à distance : si votre machine est saine, rien de tout cela ne vous atteint.

iCloud Keychain d'Apple, Windows Hello, 1Password et Bitwarden n'ont pas été testés. Unit 42 observe que d'autres fournisseurs utilisent une conception d'authentificateur cloud similaire, ce qui est un avertissement sur l'architecture, pas un constat qu'ils sont vulnérables. Quiconque vous dit « toutes les passkeys sont concernées » va au-delà de la recherche.

Ce qui vaut la peine d'être changé

Si vous êtes un particulier. Le seul vrai verrou ici est l'unique prérequis : garder la machine exempte de malware. La recommandation d'Unit 42 elle-même est d'investir dans la protection des terminaux et de traiter les passkeys comme une couche d'une stratégie plus large, pas comme une ligne d'arrivée. Pour vos comptes les plus sensibles, messagerie, banque, registrar de domaine, une clé de sécurité matérielle est l'option liée à l'appareil que cette recherche ne touche pas, puisque rien n'est synchronisé vers une enclave cloud. C'est un compromis, pas un verdict : vous gagnez en résistance à cette classe d'attaque et vous perdez le confort de la synchronisation entre appareils.

Si vous exploitez un service. Le correctif concret est côté serveur et il est nommé : exiger userVerification et valider réellement le flag UV dans la réponse d'authentification. Ce n'est pas hypothétique, eBay acceptait des authentifications sans vérification utilisateur alors que userVerification était réglé sur required, et l'a corrigé après le rapport d'Unit 42. GitHub a correctement rejeté la même attaque. Une implémentation solide tient ; une implémentation inégale, non. Comme l'a résumé l'analyste Justin Greis dans Computerworld : « The specification is sound, but the ecosystem implementing it is uneven. » (« la spécification est solide, mais l'écosystème qui l'implémente est inégal »).

Au-delà, les mesures documentées par les chercheurs et les analystes cités dans Computerworld : valider l'attestation de la clé d'appareil à l'enrôlement, surveiller les usages anormaux de passkeys, déployer de l'EDR et de l'ITDR, fixer une politique explicite sur les identifiants synchronisés par opposition à liés à l'appareil, et répéter les procédures de récupération, parce que la récupération et le ré-enrôlement sont précisément ce dont ces attaques abusent.

Ce qu'il ne faut pas conclure

Plusieurs affirmations qui circulent cette semaine ne sont pas soutenues par la recherche, et les répéter serait une erreur :

• « Les passkeys sont mortes / cassées. » Contredit par écrit par Unit 42 et SecurityWeek.
• « La cryptographie a été cassée. » Elle ne l'a pas été, explicitement.
• « Revenez aux mots de passe. » Aucune source ne le recommande, et cela réintroduirait le phishing et la réutilisation d'identifiants, précisément les attaques que les passkeys éliminent.
• « C'est un CVE activement exploité. » Aucun CVE n'avait été attribué au 3 août, et aucune exploitation dans la nature n'a été signalée.
• « Apple et Microsoft sont concernés aussi. » Non testés. Ce n'est pas la même chose.

Le résumé honnête revient à Unit 42 eux-mêmes : les passkeys sont « a meaningful step forward in authentication security » (« une avancée significative dans la sécurité de l'authentification ») parce qu'elles suppriment les secrets partagés et, avec eux, des classes entières d'attaques. Cette recherche n'inverse pas cela. Elle montre que l'écosystème construit autour des passkeys, enrôlement, récupération, synchronisation cloud, mérite le même examen que celui déjà appliqué à la cryptographie.

La leçon plus profonde, soulevée par J. Wolfgang Goerlich dans Computerworld, est celle qu'il faut garder : les passkeys synchronisées ont réintroduit un risque de portabilité des identifiants que les authentificateurs liés à l'appareil n'ont jamais eu. Le confort entre appareils a un prix, et c'est la première fois qu'on peut le voir clairement.

Sources

• Arie Olshtein, « Pass the Passkey: A Novel Attack Surface in Passwordless Authentication », Palo Alto Networks Unit 42, 3 août 2026, source primaire, éditeur de sécurité commercial.
• BleepingComputer, 3 août 2026, première couverture, note qu'aucun CVE n'est attribué.
• The Hacker News, 3 août 2026, « the attacks go after the code around the passkey » (« les attaques visent le code autour de la passkey »).
• SecurityWeek, 5 août 2026, « That does not mean passkeys are broken » (« cela ne signifie pas que les passkeys sont cassées »).
• Computerworld, Evan Schuman, 5 août 2026, commentaires d'analystes (Dickson, Greis, Goerlich, Levine, Finkelstein).
• Biometric Update, 7 août 2026, position constante de la FIDO Alliance, aucune exploitation dans la nature.

Chiffres et déclarations vérifiés le 9 août 2026. Google n'avait fait aucune déclaration publique sur le fond à cette date ; c'est le point le plus susceptible d'avoir changé depuis.