--- service: "Publicasta" schema_version: "1.0" article_id: 339 title: "Les passkeys ne sont pas magiques: ce que Pass-ta-key change vraiment" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=fr" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-08-16T17:34:01+00:00" updated_at: "2026-08-16T17:35:09+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=de" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=de" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=en" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=en" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=es" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=es" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/passkeys_without_panic_pass_ta_key_webauthn_2026_08_16.json?lang=zh" --- # Les passkeys ne sont pas magiques: ce que Pass-ta-key change vraiment > Un guide sans panique sur ce que les passkeys bloquent, ce qu’elles ne couvrent pas côté endpoint et comment vérifier WebAuthn. La polémique d’août autour de Pass-ta-key ne doit pas pousser à abandonner les passkeys. Elle doit pousser à les déployer avec un modèle de menace plus honnête. Unit 42 a décrit des attaques contre des passkeys synchronisées de Google Password Manager dans Chrome sur Windows. Ars Technica a apporté le contrepoids utile: ce n’est pas la mort des passkeys, mais la preuve que “résistant au phishing” ne veut pas dire “résistant à un ordinateur déjà infecté”. ![Schéma montrant le phishing bloqué par les passkeys, le risque endpoint compromis et les clés matérielles pour comptes sensibles](https://publicasta.com/storage/projects/9/pages/339/2026/08/647a35ae-2aea-4a2d-8fb9-5bb778734885.webp) ## Ce qui s’est passé, et ce qu’il ne faut pas conclure Le travail de Unit 42 vise un environnement précis: Google Password Manager, Chrome sur Windows, un cloud authenticator et de la confiance d’appareil appuyée sur TPM. Les variantes s’appellent Pass-ta-key, Silver Pass-ta-key et Golden Pass-ta-key. Le point essentiel est que toutes supposent du malware déjà présent sur l’appareil au départ. Ce n’est donc pas une page de phishing qui vole une passkey comme un mot de passe, ni une cassure générale de WebAuthn. La conclusion correcte est plus étroite. Dans cet environnement, du code local malveillant peut abuser de l’état du navigateur, de l’enrôlement de l’appareil, de la récupération de compte et de choix de user verification autour de passkeys synchronisées. Selon la configuration du relying party, cela peut permettre un accès sans nouveau geste visible, contourner une vérification attendue ou extraire du matériel synchronisé utile. C’est sérieux, mais ce n’est pas la fin de la résistance au phishing. Ars a raison de rappeler le contexte. Quand l’endpoint est déjà compromis et que la session utilisateur est de confiance, beaucoup de couches deviennent attaquables: cookies, jetons OAuth, profils de navigateur, coffres de mots de passe, fichiers, notifications et écrans de récupération. Les passkeys remplacent les secrets partagés et empêchent le piège du faux site. Elles ne remplacent pas l’antimalware, l’EDR, l’isolation du système et la réponse à incident. ## Comment une passkey protège Une passkey est une crédential FIDO/WebAuthn fondée sur une paire de clés. L’authenticator crée une clé pour un relying party précis. Le service garde la clé publique; la clé privée reste sous le contrôle de l’authenticator ou du fournisseur. Au login, le service envoie un challenge, l’authenticator signe des données liées au bon origin, puis le navigateur renvoie une assertion. Selon la politique, l’utilisateur déverrouille l’appareil, saisit un PIN, utilise la biométrie ou touche une clé. Cette architecture change l’économie de l’attaque. Un faux formulaire ne reçoit plus un secret réutilisable. Une fuite serveur ne donne pas de hash de mot de passe à tester ailleurs. Le credential stuffing perd sa matière première. FIDO et W3C parlent de connexion résistante au phishing parce que la réponse cryptographique est liée à l’origine légitime, pas à l’apparence d’une page. Mais cette résistance ne couvre pas tout. Elle signifie qu’un site distant ne doit pas capturer un secret réutilisable. Elle ne signifie pas qu’un ordinateur infecté ne peut pas agir dans le profil déjà autorisé, déclencher des flux de confiance, attendre le déverrouillage, lire un état local mal protégé ou utiliser des sessions actives. Une promesse de sécurité a toujours des limites; celles des passkeys sont larges, pas infinies. ## Ce que Unit 42 montre vraiment L’article de mars de Unit 42 expliquait les mécanismes peu visibles de Google Cloud Authenticator pour les passkeys synchronisées. Le travail d’août montre comment Chrome sur Windows, les données locales de synchronisation, TPM et la confiance d’appareil peuvent créer des hypothèses risquées. Le périmètre doit rester clair: Google Password Manager dans Chrome sur Windows avec TPM, divulgation responsable et malware préalable sur la machine. Trois leçons ressortent. La confiance d’appareil ne doit pas devenir une foi aveugle quand du code hostile tourne déjà au même endroit que le navigateur. User verification doit être explicitement requise pour les comptes et actions sensibles; “preferred” peut être trop faible. Enfin, la synchronisation est utile et souvent meilleure que le retour aux mots de passe, mais elle rend recovery, backup et onboarding critiques. Ce n’est pas un plaidoyer contre toutes les passkeys synchronisées. Pour un utilisateur ordinaire, elles sont souvent un excellent compromis: moins de phishing réussi, moins de mots de passe oubliés, moins de réutilisation. Pour administrateurs, finances, dépôts de code ou dirigeants, il faut envisager des clés matérielles, des appareils gérés, du conditional access et une inscription plus stricte. ## Pourquoi elles restent utiles Le phishing de mots de passe reste industriel. La réutilisation transforme une brèche en prise de plusieurs comptes. Les codes OTP et SMS se capturent par des kits adversary-in-the-middle. Les passkeys réduisent ces risques directement. La bonne réaction aux titres anxiogènes est donc de les garder et d’ajouter de l’hygiène endpoint, pas de revenir à un mot de passe faible. Les services doivent aussi mieux implémenter WebAuthn. Un challenge doit être unique, imprévisible, court et lié à la session. Le serveur doit vérifier origin, relying party ID, signature et absence de replay. User verification doit être obligatoire quand l’usage attend une protection MFA. L’ajout d’une nouvelle passkey doit passer par une session récemment vérifiée, déclencher une notification et protéger les options de récupération. L’aide Google décrit les passkeys comme une alternative simple et sûre aux mots de passe. C’est utile pour le public, mais incomplet sans contexte: les passkeys synchronisées impliquent stockage chiffré, enrôlement, récupération et état local du navigateur. L’utilisateur ne tape pas une clé privée dans un faux site; le malware peut viser l’écosystème autour de cette clé. ## Conseils aux particuliers Gardez les passkeys sur les comptes importants. Utilisez un verrouillage solide sur chaque appareil capable d’approuver une connexion. Supprimez les anciens téléphones, ordinateurs et navigateurs depuis les pages de sécurité. Vérifiez email et téléphone de récupération, car la récupération reste souvent la porte la plus fragile. N’utilisez pas un ordinateur partagé pour la messagerie principale, la banque, un compte développeur ou une console cloud. Limitez les extensions de navigateur. Une extension large voit trop près des pages, prompts et sessions. Mettez à jour système et navigateur. Après infection, traitez le nettoyage comme un incident d’identité: révoquez les sessions, examinez les passkeys récentes, retirez les appareils inconnus, contrôlez les règles de messagerie et les autorisations OAuth. Nettoyer le malware sans revoir l’état du compte laisse du risque. Pour les comptes très sensibles, ajoutez une clé de sécurité matérielle et gardez une seconde clé de secours. C’est moins confortable que la synchronisation, mais cela réduit la dépendance au poste de travail ordinaire. Ce n’est pas magique non plus: recovery et sécurité après connexion restent décisifs. ## Conseils aux organisations Une organisation doit classifier avant de déployer. Quels utilisateurs font surtout face au phishing opportuniste? Qui peut modifier l’identité, payer, déployer en production ou lire des données réglementées? Quels appareils sont gérés, chiffrés, patchés et surveillés? Quels fournisseurs de passkeys sont autorisés? Où la synchronisation est-elle acceptable et où faut-il des clés matérielles ou des appareils gérés? Pour les comptes ordinaires, les passkeys synchronisées peuvent dépasser largement mot de passe plus SMS. Pour les rôles privilégiés, la politique peut exiger des hardware keys, des appareils conformes, des postes d’administration et une élévation temporaire. Il faut aussi séparer la ligne Unit 42 sur Google/Chrome/Windows de la ligne SpecterOps/Microsoft Entra sur WebAuthn, Windows 11, assertion logging et replay validation. Ce ne sont pas un seul bug; c’est une même leçon sur les détails. La réponse à incident doit suivre. Quand un endpoint est compromis, il ne suffit pas de réinitialiser un mot de passe. Il faut révoquer les sessions, retirer les appareils, revoir les passkeys ajoutées, changer les facteurs de récupération, contrôler OAuth, réenrôler la confiance et lire les journaux. Passwordless exige des playbooks passwordless. ## Conclusion calme Les passkeys ne sont ni mortes ni magiques. Elles améliorent fortement la connexion parce qu’elles retirent le secret réutilisable. Elles réduisent phishing, credential stuffing et réutilisation de mots de passe. Elles ne suppriment pas malware, recovery faible ou mauvaise implémentation WebAuthn. La règle est simple: les garder, protéger les appareils, utiliser des clés matérielles pour le très critique et construire WebAuthn comme un protocole sérieux.