Des chercheurs de Palo Alto Networks (Unit 42) ont détaillé des attaques gestionnaire mots de passe qui visent des comptes Google protégés par des passkeys. Le point clé : l’attaque ne “casse” pas la cryptographie des passkeys. Elle cherche plutôt à détourner la façon dont Chrome gère certains éléments au niveau du dispositif, notamment les clés et la vérification côté site.
Selon le rapport, un malware déjà exécuté sur la machine victime peut obtenir une authentification sans que l’utilisateur voie quoi que ce soit à l’écran, sans besoin d’empreinte ou de PIN affiché. Les scénarios décrits se concentrent sur Google Password Manager dans Chrome sur Windows, avec un module TPM (Trusted Platform Module).
Ce que les chercheurs disent (et ce qu’ils ne prouvent pas)
Les travaux portent sur des techniques post-compromise. Autrement dit, elles expliquent ce que peut faire un attaquant après avoir déjà pris le contrôle du poste. Le document ne décrit pas une exploitation observée “dans la nature”, et il ne fournit pas non plus de référence CVE, ni les versions exactes de Chrome concernées, ni un statut de correction complet.
De plus, une recherche dans la National Vulnerability Database au 3 août 2026 ne montre aucune entrée CVE correspondant aux trois méthodes nommées dans le rapport. En pratique, cela signifie que les informations connues à ce stade servent surtout à comprendre les mécanismes de risque et à guider des vérifications plus strictes, plutôt qu’à pointer une simple “rustine logicielle”.
Pourquoi “aucune cryptographie cassée” change la perspective
Un élément important du rapport est la distinction entre la cryptographie et le code qui l’entoure. Les attaques ciblent la logique autour des passkeys : comment Chrome stocke certaines clés liées à l’appareil, comment il gère la re-inscription du dispositif, et surtout si le site de destination vérifie réellement qu’un utilisateur humain a été authentifié.
En clair, même si les opérations cryptographiques sont correctement conçues, un attaquant peut tenter de contourner le “signal” de vérification (par exemple un indicateur de user verification) ou d’obtenir un élément secret conservé côté client pendant un laps de temps.
Chemin 1 : Pass-ta-key et le contrôle du bit de vérification
La première voie, appelée Pass-ta-key, vise la manière dont Chrome obtient et utilise la clé d’identité enveloppée de l’appareil. Le malware demande alors au TPM de signer une requête contrôlée par l’attaquant via les appels Windows CNG (Windows Cryptography API: Next Generation).
L’objectif est d’obtenir une assertion d’authentification valide retournée par le cloud, comme si une vérification utilisateur avait eu lieu. La différence, d’après les chercheurs, se résume à un bit : le drapeau User Verified (UV) ne serait pas positionné.
Les chercheurs indiquent que, selon l’implémentation du site “relying party”, la cérémonie d’authentification doit échouer si userVerification est fixé à required et que le bit UV n’est pas présent. Ils citent des exemples : certains sites appliqueraient la règle, tandis que d’autres l’auraient d’abord acceptée dans un test avant de corriger un écart de validation suite à la divulgation.
Conséquence : ce chemin montre comment une partie de la sécurité dépend du contrôle côté site. Si le site ne valide pas correctement la présence de l’élément de preuve (ici le bit UV), l’attaque peut rendre l’authentification indiscernable d’une vraie vérification aux yeux du serveur.
Chemin 2 : Silver Pass-ta-key via la ré-inscription et une clé “remplacée”
La deuxième technique, Silver Pass-ta-key, se concentre sur une couche différente : la ré-enrôlement (re-enrollment) du dispositif. L’idée est de forcer Chrome à repasser par une phase où la création de la clé liée à la vérification utilisateur ne serait pas immédiate.
Pendant cette fenêtre, un attaquant pourrait enregistrer une clé contrôlée par lui. Le rapport précise que les assertions signées avec cette clé portent alors un indicateur UV positionné, ce qui pourrait permettre des connexions ultérieures depuis l’environnement de l’attaquant, même après le compromission initiale.
Le document souligne que le code Chromium consulté confirme l’existence d’un état différé (notamment un “deferred_uv_key_creation”). Toutefois, il ne suffit pas de constater cet état dans le code public : les chercheurs expliquent aussi qu’il reste ouvert, pour les versions récentes de Chrome, de vérifier comment exactement le serveur gère et valide une substitution de clé.
Selon Unit 42, une mitigation pertinente consisterait à vérifier si une clé nouvellement enregistrée provient bien d’un matériel sécurisé (attestation), avant de l’accepter.
Chemin 3 : Golden Pass-ta-key et la récupération de secrets
Le troisième scénario, Golden Pass-ta-key, est plus “direct” dans sa cible : il vise le secret utilisé pour déchiffrer des passkeys synchronisées. Les chercheurs rapportent qu’un malware peut déclencher la ré-inscription, puis lire un secret depuis la mémoire du processus Chrome pendant qu’il y serait présent en clair.
Dans le rapport, ce secret correspond à une valeur de 32 octets connue sous le nom de Security Domain Secret (SDS). Une fois le SDS récupéré, l’attaquant pourrait être en mesure de récupérer des clés privées de passkeys synchronisées.
Le document indique également que des changements antérieurs auraient été observés : Google aurait retiré une exposition du SDS dans des journaux FIDO, et au niveau d’au moins un site (mentionné via l’exemple d’eBay), la validation du bit UV aurait été corrigée. Cependant, ces ajustements ne ferment pas nécessairement le chemin décrit, car les chercheurs affirment que le secret atteint quand même le client et demeure en mémoire pendant la phase concernée.
Où les données sont stockées (et pourquoi la reconnaissance locale compte)
Les attaques décrites commencent, dans tous les cas, par une phase de reconnaissance locale. Le rapport explique que les enregistrements de crédentials synchronisés sont conservés sous un chemin lié au profil utilisateur, notamment :
- %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB
Selon Unit 42, un processus sans privilèges élevés pourrait accéder à suffisamment de métadonnées pour identifier les relying parties et les noms d’utilisateurs associés aux passkeys, ainsi que certains identifiants de crédential et du matériel chiffré.
Cette étape ne donne pas forcément l’accès final, mais elle aide l’attaquant à comprendre quoi cibler et à structurer les étapes suivantes.
Limites connues : versions, couverture et signaux publics
Au 3 août 2026, les chercheurs indiquent qu’il n’existe pas de notification claire publiée décrivant des changements spécifiques correspondant exactement aux trois techniques. Les recherches menées sur des documents publics Chrome et sur des pages d’aide/communiqués d’un site cité ne permettent pas d’identifier une mesure de rotation ou de révocation ciblée au niveau d’un SDS.
Pour les utilisateurs, la documentation publique de Google évoque principalement des actions comme changer le PIN du Password Manager ou supprimer les données du Password Manager. Le rapport ne confirme pas explicitement si ces actions invalident immédiatement un secret déjà acquis par un attaquant.
À ce stade, l’absence d’éléments concrets “avant/après” rend la compréhension du niveau de correction encore incomplète. La mise à jour de l’histoire dépend aussi d’éventuels retours de Google et d’autres parties.
Que devraient faire les sites et les systèmes de connexion
Le rapport met l’accent sur des recommandations orientées “validation” plutôt que sur des correctifs purement côté client. Les points principaux :
- Pour les relying parties : définir userVerification sur required et vérifier le bit UV réellement retourné, au lieu de se fier à la seule configuration de la requête.
- Pour les providers de crédentials : attester les clés nouvellement enrôlées, renforcer les contrôles de ré-inscription et de récupération, et réduire l’exposition du “state” local des passkeys.
- Gestion des clés : éviter que des clés maîtres et des secrets sensibles se retrouvent dans des journaux côté client ou dans des zones mémoire trop exposées.
En pratique, cela revient à réduire la surface où un attaquant peut obtenir une réponse “semble valide” sans preuve qu’un humain a réellement été vérifié.
Conseil pragmatique côté utilisateur
Même si le rapport décrit des attaques nécessitant déjà la présence d’un malware sur la machine, il sert de rappel : la protection des comptes ne se limite pas à l’existence d’une passkey. La sécurité dépend aussi de l’intégrité du poste et de la capacité des sites à vérifier les signaux de vérification.
Si vous suspectez un compromis, la première étape reste de sécuriser l’environnement : analyse du système, suppression du logiciel malveillant, et ensuite seulement actions de réinitialisation (comme la gestion du PIN ou la suppression des données du Password Manager, selon ce qui est disponible et pertinent).
Conclusion : comprendre le risque autour des passkeys
Les attaques gestionnaire mots de passe décrites par Unit 42 ne “cassent” pas directement la cryptographie des passkeys. Elles exploitent plutôt des failles d’implémentation possibles autour de la chaîne d’authentification : dépendance à un bit de vérification, possibilités de ré-enrôlement avec substitution de clé, et exposition temporaire de secrets côté mémoire.
À retenir : tant que la machine reste compromise, un attaquant peut potentiellement chercher des moyens de produire des assertions valides ou d’accéder à des éléments secrets. La meilleure défense combine validation stricte côté sites, durcissement côté providers, et hygiène de sécurité côté utilisateur.
Source: https://thehackernews.com/2026/08/google-password-manager-attacks-could.html
