Une attaque qui commence sur l’appareil
Les passkeys remplacent les mots de passe partagés par une paire de clés cryptographiques. C’est un progrès important : une passkey n’est pas censée être copiée ou transmise comme un secret classique. Mais cette promesse ne dispense pas de protéger l’environnement qui l’utilise.
Dans une recherche publiée par Unit 42, trois techniques — baptisées Pass-ta-key, Silver Pass-ta-key et Golden Pass-ta-key — ciblent Google Password Manager dans Chrome sous Windows, sur des appareils équipés d’un TPM. Leur point de départ est toujours le même : un malware s’exécute déjà sur l’appareil de la victime, avec les droits d’un utilisateur ordinaire.
Ce cadre est essentiel. Il ne s’agit pas d’une attaque à distance qui casserait la cryptographie des passkeys. Il s’agit de détourner les mécanismes de confiance qui relient le navigateur, l’appareil, le gestionnaire cloud et le site auquel on se connecte.
Trois chemins de confiance mis à l’épreuve
Le premier chemin, Pass-ta-key, réutilise l’identité matérielle de l’appareil pour obtenir une assertion de connexion sans empreinte, code PIN ou interaction visible. Lorsque le service vérifie correctement le bit User Verified (UV) de WebAuthn, cette assertion devrait être refusée si une vérification utilisateur était obligatoire. Le problème apparaît lorsque le service fait confiance au paramètre de la requête sans contrôler le résultat retourné.
Le deuxième chemin, Silver Pass-ta-key, concerne la réinscription de l’appareil. Après la suppression ou l’invalidation d’un état local, Chrome peut entrer dans une phase où une nouvelle clé de vérification doit être enregistrée. La recherche décrit un scénario dans lequel une clé contrôlée par l’attaquant est inscrite pendant cette transition. Elle pourrait ensuite produire des assertions qui semblent avoir été vérifiées par l’utilisateur.
Le troisième, Golden Pass-ta-key, vise le Security Domain Secret (SDS), un secret maître de 32 octets utilisé pour déchiffrer les passkeys synchronisées. Les chercheurs expliquent qu’il peut apparaître temporairement dans la mémoire du processus Chrome lors d’une nouvelle inscription. S’il était extrait, les passkeys synchronisées pourraient être déchiffrées et réutilisées depuis l’environnement de l’attaquant.
La recherche ne dit pas que ces chemins sont exploités dans la nature, ni que toutes les versions actuelles de Chrome restent vulnérables. Elle documente un modèle de menace post-compromission et souligne que les changements de PIN ou la suppression des données ne constituent pas nécessairement une révocation démontrée d’un secret déjà volé.
Ce que l’épisode change pour les entreprises
Une passkey réduit fortement le phishing et la réutilisation de mots de passe. Elle ne transforme pas un appareil compromis en appareil fiable. Si un malware peut lire des données locales, modifier un état de réinscription ou inspecter la mémoire d’un navigateur, il peut attaquer la chaîne autour de l’authentification.
Les responsabilités sont donc partagées :
- Les services doivent exiger
userVerification: requiredquand le niveau de risque le justifie et vérifier le bit UV dans chaque réponse WebAuthn. - Les gestionnaires d’identifiants doivent protéger les parcours de récupération et de réinscription, valider l’origine des nouvelles clés et éviter d’exposer des secrets maîtres dans les logs ou la mémoire client.
- Les entreprises doivent réduire le risque sur les endpoints : mises à jour, protection contre les malwares, droits minimaux, surveillance des changements inhabituels et procédure de révocation testée.
Pour une TPE-PME, le réflexe est concret : une demande inattendue de récupération, un nouvel appareil enregistré ou un comportement inhabituel du navigateur doit déclencher une vérification, pas une validation automatique.
Passkeys et mots de passe ne s’opposent pas
Cette recherche ne justifie pas un retour aux mots de passe partout. Elle rappelle plutôt qu’aucune méthode d’authentification ne doit être évaluée isolément. Les passkeys sont pertinentes pour les services qui les prennent en charge ; des mots de passe uniques restent nécessaires pour les comptes et systèmes qui ne les acceptent pas encore.
Soclyde se situe sur ce terrain complémentaire : générer des secrets uniques, les conserver dans des coffres chiffrés local-first et garder le contrôle des données sur les appareils de l’utilisateur. Cela ne protège pas un appareil infecté et ne remplace pas les passkeys, la MFA ou la supervision. Cela évite toutefois qu’une réutilisation ou qu’un coffre cloud centralisé transforme un incident local en problème généralisé.
La leçon de Pass-ta-key tient en une phrase : la clé peut être excellente, mais la porte autour d’elle dépend toujours de l’appareil. Découvrez l’approche local-first de Soclyde.
