Ces dernières semaines, trois équipes de recherche ont mis en évidence des attaques aux passkeys qui ne rompent pas la cryptographie FIDO2 sous-jacente, mais exploitent plutôt des maillons faibles autour de l’authentification. L’objectif n’est pas de “casser” la mathématique des clés : il s’agit de réutiliser des preuves d’authentification déjà générées, de tirer parti de mécanismes de synchronisation, ou encore d’employer des clés protégées dans un contexte déjà compromis.
Le point commun est rassurant et inquiétant à la fois : les passkeys restent solides sur le plan cryptographique, mais l’ensemble du parcours (validations côté services, gestion des identités de périphériques, protections du système d’exploitation, et comportements applicatifs) peut introduire des surfaces d’attaque. Résultat : selon le scénario, un attaquant peut se faire passer pour un utilisateur, récupérer des secrets synchronisés ou produire de nouveaux éléments d’authentification sans interaction fraîche.
Pourquoi les passkeys ne suffisent pas à elles seules
Les passkeys ont été conçues pour remplacer les mots de passe réutilisables et réduire drastiquement les risques liés au phishing. En pratique, elles s’appuient sur des clés cryptographiques et des mécanismes de vérification côté application et côté identité. Or, dans les cas rapportés, les chercheurs n’ont pas cherché à dérober une clé privée “au sens classique”. Ils ont plutôt exploité des éléments déjà présents : signatures réutilisables, clés maîtres exposées temporairement, ou appels légitimes à des interfaces cryptographiques depuis une session compromise.
Autrement dit, le problème ne réside pas dans les fondations mathématiques, mais dans les contrôles périphériques : ce qui est stocké, ce qui est accepté en retour par un service cloud, ce qui est lié (ou non) à une session, et la façon dont l’utilisateur est amené à déverrouiller une clé ou non.
SpecterOps : chaîne Windows/Entra et signatures réutilisées
La première série de travaux, présentée par SpecterOps, s’appuie sur une chaîne d’attaque impliquant Windows et Microsoft Entra ID. L’enjeu : se faire passer pour des utilisateurs privilégiés tout en satisfaisant une MFA conçue pour résister au phishing.
Le mécanisme décrit ne consiste pas à extraire la clé privée d’un authentificateur (comme une YubiKey). À la place, les chercheurs indiquent que Windows aurait conservé, dans un stockage accessible, des signatures de précédentes authentifications en clair. Des utilisateurs non privilégiés (y compris à distance, selon les éléments rapportés) pourraient lire ces signatures.
Ensuite, l’attaque “enchaîne” ces signatures avec des faiblesses de validation côté Entra. Ce point est crucial : l’authentification n’est pas obtenue en cassant FIDO2, mais en faisant accepter par le service cloud une preuve déjà produite et répondant aux attentes de vérification.
Le problème côté Windows est suivi sous la référence CVE-2026-34348, une vulnérabilité d’information disclosure dans le service de journalisation d’événements Windows (Windows Event Logging Service). La portée produit listée par l’éditeur concerne Windows 10, Windows 11 et Windows Server, avec une classification CVSS de 6,5, et un correctif de Microsoft.
Microsoft a aussi indiqué avoir appliqué des atténuations concernant un sujet distinct portant sur des “passkey relay assertions”, tout en rappelant l’importance d’approches de sécurité de type principe du moindre privilège et modèle Zero Trust. Dans sa réponse, l’éditeur ne fournit pas de détails techniques complets sur la partie Entra, ce qui laisse une certaine incertitude sur la nature exacte des contrôles supplémentaires.
Unit 42 : récupération des clés privées synchronisées via Chrome
La deuxième recherche, menée par Unit 42, cible le système de passkeys synchronisées de Google Password Manager dans Chrome sur Windows. Là encore, les attaques décrites démarrent avec du logiciel malveillant déjà présent sur le poste de la victime, sans exiger d’escalade de privilèges au niveau administrateur.
Les chercheurs décrivent plusieurs chemins. Le premier abus se concentre sur la manière dont Chrome gère l’identité du périphérique afin d’obtenir des signatures permettant d’agir comme un client légitime de Password Manager, sans exiger un nouveau déverrouillage de l’appareil ni une action de l’utilisateur.
Une variante décrite permet même une démonstration contre eBay : malgré l’existence d’une demande de vérification utilisateur, Unit 42 rapporte que le site a modifié, après signalement, la façon dont il valide le drapeau de user verification pour WebAuthn.
Le scénario le plus impactant porte le nom de Golden Pass-ta-key. Il vise la Security Domain Secret, une clé maître de 32 octets utilisée pour protéger les passkeys synchronisées. Selon Unit 42, ce secret aurait été exposé dans des journaux de périphériques côté Chrome. Après le rapport, Google aurait supprimé cette exposition dans les sorties de journalisation, mais les chercheurs affirment que le secret reste temporairement présent dans la mémoire du processus au moment de la réinscription.
Avec cette clé maîtresse, un attaquant peut récupérer les clés privées des passkeys synchronisées de la victime. Unit 42 souligne aussi une limite importante du modèle : l’implémentation actuelle ne donnerait pas de mécanisme simple pour faire tourner (rotate) ou révoquer la Security Domain Secret. Concrètement, cela peut rendre la compromission plus persistante qu’une session isolée.
Dirk-jan Mollema : Windows Hello for Business sans nouveau PIN
La troisième recherche, menée par un chercheur indépendant, Dirk-jan Mollema, se concentre sur Windows Hello for Business. Sur la plupart des appareils Windows modernes, la clé de support est protégée par le TPM et ne peut pas être exportée facilement. Cependant, l’étude insiste sur un point réaliste : un logiciel exécuté dans une session utilisateur compromise peut quand même utiliser cette clé non exportable via des interfaces cryptographiques Windows.
Mollema décrit qu’un processus avec de faibles privilèges, une fois la session déjà ouverte, peut appeler des interfaces pour utiliser la clé Windows Hello for Business sans déclencher une demande de PIN ou de biométrie. Ensuite, cette clé est utilisée comme crédential FIDO2 pour interagir avec Microsoft Entra ID.
Un aspect technique important est le comportement des challenges WebAuthn côté Entra : selon l’étude, un challenge serait valide pendant cinq minutes et ne serait pas lié à une session, à un utilisateur ou à un tenant de manière stricte. Cela permet une chaîne où un challenge obtenu sur le système de l’attaquant peut être repris sur la machine de la victime : signé localement grâce à Windows Hello, puis renvoyé en tant qu’assertion WebAuthn.
Le résultat peut répondre à des règles d’accès conditionnel imposant une authentification résistante au phishing. L’étude mentionne aussi que le token produit pourrait manquer une revendication (device ID), ouvrant une voie vers l’enregistrement de périphériques et la persistance via des jetons de type Primary Refresh Token.
Enfin, l’auteur note une limite de l’ensemble des rapports : les matériaux publics ne permettent pas de conclure si les comportements Entra observés dans ces travaux partagent la même cause sous-jacente, ou s’ils exploitent des contrôles différents qui conduisent à des résultats similaires.
Une cryptographie forte, mais un “contexte” parfois faible
Faut-il considérer ces trois résultats comme un seul et même bug ? Les chercheurs recommandent de ne pas les fusionner trop rapidement. Les scénarios diffèrent à plusieurs niveaux :
- SpecterOps s’appuie sur des assertions signées réutilisables, exposées via Windows et acceptées par un chemin d’authentification cloud.
- Unit 42 montre des manipulations autour de la confiance client, de la vérification utilisateur, de la récupération et de la protection des clés synchronisées dans un navigateur.
- Mollema illustre comment des logiciels dans une session Windows déjà active peuvent utiliser une clé matérielle liée pour produire de nouveaux éléments d’authentification.
Malgré ces différences, le message reste convergent : une compromission du poste ou de la session peut permettre de réutiliser des preuves, d’extraire ou reconstruire des secrets synchronisés, ou de générer une authentification “fraîche” sans les vérifications attendues par les politiques.
Quelles mesures prendre dès maintenant
Pour Windows, la recommandation immédiate est d’appliquer les mises à jour de sécurité publiées par Microsoft au sujet de la CVE-2026-34348. Au-delà des correctifs, les défenseurs doivent reconsidérer la façon dont les services traitent les assertions WebAuthn et les exigences de user verification demandées.
La logique est simple : si un service attend un comportement d’authentification fort, il doit l’exiger réellement dans ses validations, et pas seulement dans la politique. Sur les postes, les protections doivent traiter les passkeys, les flux de récupération et la mémoire applicative du navigateur comme des zones sensibles au même titre qu’on protégerait des identifiants.
Côté Entra, l’étude suggère également une vigilance accrue sur des sign-ins Windows Hello for Business sans identifiant d’appareil et sur des enregistrements de périphériques inattendus. Les chercheurs notent que ni les passkeys synchronisées ni les passkeys liées à l’appareil ne résolvent automatiquement les erreurs d’implémentation plus en amont ou plus loin dans la chaîne d’authentification.
Microsoft indique par ailleurs augmenter le niveau d’activation des passkeys : à partir du 1er septembre 2026, les utilisateurs Entra ID actuellement configurés pour l’authentification via SMS ou voix seront automatiquement activés pour les passkeys et encouragés à les enregistrer. L’éditeur prévoit aussi la mise hors service de la livraison SMS/voix fournie par Microsoft au 1er février 2027.
Conclusion : renforcer les contrôles autour des passkeys
Les attaques aux passkeys rapportées montrent que la sécurité ne se limite pas à la robustesse cryptographique. Lorsque des signatures peuvent être réutilisées, lorsque des secrets synchronisés se retrouvent temporairement en mémoire, ou lorsque des clés protégées sont mobilisables depuis une session compromise sans nouvel acte de l’utilisateur, l’authentification peut devenir exploitable.
La bonne nouvelle, c’est que la correction existe souvent : correctifs système, durcissement des validations côté services, et amélioration des défenses endpoint. La priorité pour les équipes sécurité est de réduire les chances qu’un attaquant obtienne une session prête à l’emploi, et de surveiller les comportements d’authentification qui s’écartent des attentes.
Source: https://thehackernews.com/2026/08/new-passkey-attacks-can-recover-synced.html
