D’abord la conclusion. AES-256-GCM répond à « le champ du mot de passe, dans le fichier local, est-il du texte en clair ? ». Il ne répond pas à « qui a le droit d’obtenir la clé ». Le 30 juillet 2024, Google écrit que DPAPI, sous Windows, bloque les autres comptes et une copie du disque après extinction, pas un programme qui s’exécute déjà avec l’identité de l’utilisateur connecté. Depuis Chrome 127, les cookies passent d’abord au chiffrement lié à l’application : la frontière se resserre de « l’utilisateur » vers « le programme du navigateur ». Aucune de ces deux frontières ne signifie « aucun programme de cette machine ne peut lire ».
Répondre à la recherche en une phrase
Chercher « mot de passe enregistré chiffré, donc un programme malveillant ne le voit pas » vise presque toujours la même vérification : après avoir cliqué sur Enregistrer, un autre programme de cet ordinateur peut-il encore lire le texte en clair ? Le nom de l’algorithme ne tranche pas. Le blog sécurité de Google formule l’ancienne frontière Windows sans détour. Chrome protège les cookies, les mots de passe et d’autres données sensibles avec l’interface de protection des données du système, DPAPI. Cette protection vise les autres utilisateurs de la machine, et quelqu’un qui emporte le disque une fois l’ordinateur éteint. Un programme capable d’exécuter du code avec l’identité de l’utilisateur déjà connecté reste dans ce périmètre.
Cette note s’adresse à deux lecteurs. Le premier révise une phrase du type « le navigateur chiffre déjà les mots de passe, on n’a plus à se soucier de ce qui est écrit sur le disque ». Le second a vu passer un article de sécurité ces jours-ci et veut savoir ce que « chiffré », dans la page de réglages, prouve vraiment. On ne décrit pas comment extraire le mot de passe de quelqu’un d’autre, et ceci ne remplace pas le mode d’emploi du générateur de mots de passe. À emporter : trois faits que l’on peut séparer. Ce que le texte chiffré prouve. Ce que l’enveloppe de la clé prouve. Et ce que le rapport du 25 septembre 2026 ne prouve pas.
L’AES-256-GCM sur le disque prouve seulement l’absence de clair
Les navigateurs de la famille Chromium écrivent les connexions enregistrées dans le profil local. Sur les champs récents, le mot de passe est encapsulé en AES-256-GCM. Ouvrir ce fichier dans un éditeur de texte ne montre pas le mot de passe du site : c’est exact. GCM, ici, ajoute une propriété utile. Sans la clé correspondante, modifier un seul octet fait échouer le contrôle d’intégrité. On ne peut pas traiter ce texte chiffré comme un clair que l’on réécrirait en douce.
Le navigateur doit pourtant remplir le champ la prochaine fois que le formulaire de connexion s’ouvre. La clé ne peut donc pas vivre seulement dans une phrase que vous seriez le seul à retenir. Le navigateur de cette machine doit pouvoir la reprendre une fois la session déverrouillée. La question utile cesse d’être « l’algorithme est-il solide » et devient « qui a le droit de demander cette clé au système ». Un algorithme peut être très solide. Si le droit est accordé à « l’utilisateur Windows déjà connecté », un programme lancé sous cette identité se tient du même côté que le navigateur.
C’est aussi pour cela que « le même nom d’algorithme » ne désigne pas le même arrangement de clés. Un fichier chiffré dans le navigateur avec une phrase que vous saisissez, en AES-256-GCM, reste fermé pour le cloud et pour un autre programme qui n’a pas cette phrase. Le gestionnaire de mots de passe du navigateur a un autre objectif : remplir le formulaire tout seul. Le droit d’utiliser la clé doit rester du côté du navigateur, sur cette machine. Voir AES-256-GCM dans les deux cas ne confond pas les deux façons de détenir la clé.
La frontière que Google a écrite lui-même
La même note du 30 juillet 2024 distingue les systèmes. macOS passe par le trousseau. Linux passe par le portefeuille du système, par exemple kwallet ou gnome-libsecret. Windows passe par DPAPI. La phrase sur « un programme lancé par l’utilisateur déjà connecté » décrit DPAPI sous Windows. Ne la collez pas telle quelle sur chaque Mac. Le trousseau peut afficher une confirmation du système : ce n’est pas la même interaction qu’un déballage silencieux par n’importe quel processus du même compte.
Sous Windows, DPAPI attache la clé au matériel de connexion de cet utilisateur. Un autre compte Windows qui ouvre votre dossier de profil, ou quelqu’un qui retire le disque après extinction, sans votre secret de connexion, ne déchiffre pas par défaut. C’est la moitié de « c’est chiffré » qui tient dans une description de produit. L’autre moitié est le trou que Google écrit en clair : un programme malveillant qui peut déjà s’exécuter sous l’utilisateur courant peut appeler la même interface système que le navigateur et demander la clé. Le chiffrement n’a pas cessé de fonctionner. La frontière était dessinée autour des autres utilisateurs, pas autour des autres processus du même utilisateur.
Quand une revue de sécurité affirme « le gestionnaire utilise AES-256-GCM, donc un programme malveillant local ne peut pas lire », il faut couper la phrase en deux. La première moitié se vérifie : le fichier n’est pas le mot de passe en clair. La seconde, sur la génération DPAPI, contredit la note publique de Google. Ce qu’il faut chercher ailleurs, c’est si ce navigateur a déjà fait passer ce secret vers la frontière suivante. Le nom de l’algorithme ne le dit pas.
Chrome 127 resserre la frontière de l’utilisateur vers le programme
La même note continue. Chrome 127, sous Windows, introduit le chiffrement lié à l’application (app-bound encryption). Les données ne sont plus ouvertes par « n’importe quel programme qui tourne sous l’utilisateur courant ». La clé est liée à l’identité du programme du navigateur. Un composant du système vérifie que l’appelant est un navigateur de confiance, puis remet la clé. L’ordre de migration écrit par Google est celui-ci : d’abord les cookies. Les mots de passe, les données de paiement et les autres jetons de connexion persistants sont des objets que les versions suivantes doivent étendre. Ils ne sont pas tous migrés le jour de la publication de Chrome 127.
En 2026, les descriptions publiques côté investigation — par exemple la note d’ElcomSoft de janvier 2026 — disent ceci. Sur les profils Chrome et Edge récents où le chiffrement lié à l’application est déjà actif, un programme extérieur qui ne sait faire que l’ancien déballage « utilisateur courant » échoue. Cette nouvelle frontière arrête un processus ordinaire qui se tient hors du navigateur. Elle ne met pas « l’intérieur du processus du navigateur » dehors. Une extension malveillante, ou du code qui s’exécute déjà dans ce processus, reste à l’intérieur. Le chiffrement lié à l’application change le droit de l’appelant. Il ne dit pas : « dès qu’on a écrit AES-256-GCM, la logique de remplissage en mémoire ne voit plus le mot de passe ».
Deux phrases ne peuvent donc pas se remplacer. La première : « mon Chrome est au-dessus de 127, donc les mots de passe enregistrés ont forcément migré ». En juillet 2024, Google classe les mots de passe parmi les objets à étendre plus tard. Un numéro de version ne coche pas cette case tout seul. La seconde : « la presse montre encore quelqu’un qui lit un mot de passe avec l’ancien déballage, donc le chiffrement lié à l’application ne sert à rien ». Cela montre seulement qu’un profil, ou une partie des données, est encore sur l’ancienne frontière — ou que l’échantillon décrit justement cette ancienne frontière. Cela ne prouve pas que la nouvelle frontière a été publiquement écrite comme déjà cassée.
| Ce que vous voyez | Ce que cela peut soutenir | Ce que cela ne soutient pas |
|---|---|---|
| Le champ du mot de passe est en AES-256-GCM | Le fichier local ne contient pas le mot de passe en clair | Aucun programme de cette machine ne peut lire |
| Windows enveloppe la clé avec DPAPI | Un autre compte, ou une copie du disque prise après extinction, n’ouvre pas par défaut | Un programme lancé par l’utilisateur connecté n’ouvre pas |
| Chrome 127, chiffrement lié à l’application, d’abord les cookies | Sur les données déjà migrées, l’ancien déballage d’un programme extérieur échoue | Le champ du mot de passe de votre machine a forcément migré ; l’intérieur du processus ne lit plus |
| Le gestionnaire contient une entrée | Ce site a déjà été enregistré | Quelle génération d’enveloppe protège encore la clé |
| Désactiver « proposer d’enregistrer les mots de passe » | Les prochaines connexions peuvent ne plus entrer dans la liste | Les entrées déjà présentes sont supprimées |
Ce que le rapport du 25 septembre peut prouver
Le 25 septembre 2026, K7 Labs publie l’analyse d’une famille de programmes Windows. Dans les jours qui suivent, plusieurs médias sécurité la reprennent. Le rapport dit que le programme lit, dans plusieurs navigateurs Chromium, les mots de passe enregistrés, les cartes de paiement, l’historique et les sessions, et qu’il lit aussi l’historique et les cookies de Firefox. Les champs de mot de passe récents sont stockés en AES-256-GCM. La clé est rendue accessible par la protection des données au niveau de l’utilisateur Windows. K7 précise ne pas avoir établi jusqu’où ce programme a été diffusé, ni combien de machines il a touchées.
Cette description correspond à l’ancienne frontière du paragraphe précédent. Ce droit appartient à « l’utilisateur courant ». Un programme de la même session peut se tenir à l’intérieur. AES-256-GCM ne fait que garder le champ hors du texte en clair. Le rapport n’est pas écrit comme « le chiffrement lié à l’application de Chrome a déjà été contourné ». Il ne fournit pas non plus un nombre de victimes que l’on pourrait transformer en « votre Chrome est forcément touché ». Lire le nom de l’algorithme dans le titre comme « le chiffrement ne marche plus », ou comme « mon gestionnaire est donc absolument sûr », va plus loin que le texte.
Le rapport rappelle aussi deux éléments que l’on mélange. La session et le mot de passe enregistré ne sont pas la même chose. Une fois la session emportée, l’attaquant peut, pendant un temps, utiliser l’état déjà connecté. Changer le mot de passe sur le site d’origine invalide la prochaine connexion par mot de passe. Cela n’invalide pas forcément une session déjà émise. Pour traiter la session, il faut se déconnecter dans la liste des appareils ou des sessions du compte, ou attendre que le site révoque. Cela n’a rien à voir avec « le chiffrement du gestionnaire est-il solide ». Pour la vérification plus ancienne — changer le mot de passe ne retire pas une session déjà établie — voir la note sur les passkeys. Ce n’est pas le même réglage.
Ne déchiffrez pas votre gestionnaire « pour voir si l’article est vrai ». N’utilisez pas non plus un vrai mot de passe de banque, de messagerie ou de console cloud comme essai. Les contrôles ci-dessous regardent seulement s’il existe des entrées enregistrées, et si l’invite d’enregistrement est encore active. Extraire le texte en clair, ou exporter toute la base, n’entre pas dans ce contrôle.
Vérifier sur place : la liste, pas la base
Un slogan, ou le titre d’un article, ne remplace pas les réglages de ce navigateur-ci. Un compte de test que vous pouvez jeter suffit. Les quatre étapes se font dans le navigateur ouvert. Inutile de copier le dossier de profil.
- Ouvrez le gestionnaire de mots de passe du navigateur (réglages « Mots de passe / saisie automatique », ou la page de gestion des mots de passe dans la barre d’adresse). Regardez seulement la liste des sites : messagerie, banque, console cloud, hébergement de code ont-ils chacun une ligne ? N’affichez pas le mot de passe en clair. N’exportez pas.
- Trouvez « Proposer d’enregistrer les mots de passe », ou l’interrupteur équivalent. Il décide si la prochaine connexion entrera encore dans la liste. Le couper ne supprime pas les entrées déjà là. Pour supprimer, retirez les lignes une par une, ou utilisez l’effacement des mots de passe enregistrés que le navigateur propose.
- Ouvrez la page « À propos » et vérifiez que le navigateur reçoit encore les mises à jour officielles. Notez le numéro de version. Ce numéro ne prouve pas que le champ du mot de passe a migré vers le chiffrement lié à l’application. La page de réglages n’affiche pas non plus DPAPI, ni « lié à l’application ». N’allez pas chercher, pour cela, un préfixe de clé dans le dossier de profil.
- Si vous soupçonnez qu’un programme d’origine inconnue tourne déjà sur cet ordinateur : ne cliquez pas sur « Afficher le mot de passe » ici. Passez sur un appareil auquel vous faites encore confiance, déconnectez les autres sessions des sites importants, et changez les mots de passe. N’en réutilisez aucun d’un site à l’autre. Cette étape traite les conséquences. Elle ne consiste pas à ouvrir la base sur place « pour voir si on peut lire ».
Le numéro de version ne dit pas la génération de la clé
Chrome 127 est la version où le chiffrement lié à l’application commence à couvrir les cookies. Ce n’est pas la version où « tous les mots de passe enregistrés ont changé d’enveloppe le jour même ». Voir 130, 140 ou plus haut dit seulement que la version principale est postérieure à ce point de départ. Les mots de passe ont-ils fini de migrer ? La note officielle laisse la plage « versions suivantes », et l’interface n’affiche pas la génération d’enveloppe. Si vous recopiez le numéro dans une grille de revue, écrivez à côté « on ne peut pas en déduire que le gestionnaire est déjà lié à l’application ». Ne cochez pas la case.
L’invite d’enregistrement est l’interrupteur d’entrée
Beaucoup de mots de passe entrent dans la liste non pas parce qu’une page de chiffrement « synchronise un envoi », mais parce que le navigateur a demandé, après une connexion réussie, s’il fallait enregistrer — et que quelqu’un a accepté. L’entrée se retrouve alors derrière la frontière décrite plus haut. Un mot de passe qui n’existe que dans cet onglet, si vous refusez l’enregistrement, ne devient pas une ligne du gestionnaire. Refuser l’enregistrement ne prouve pas qu’un script de la page n’a pas envoyé le mot de passe : cela se contrôle à part, dans le panneau Network. Cela prouve seulement que vous n’avez pas remis cette chaîne à la liste des mots de passe enregistrés.
Quatre lectures trop larges de « c’est chiffré »
La première consiste à lire AES-256-GCM comme « un programme malveillant ne peut pas lire ». L’algorithme dit que le champ n’est pas en clair, et qu’on ne peut pas modifier le texte chiffré sans la clé. Si la clé est emballée par DPAPI pour l’utilisateur courant, Google a déjà écrit qu’un programme lancé sous cette identité n’est pas tenu à l’écart : il peut demander la même clé. Le nom de l’algorithme et l’emplacement de la frontière sont deux lignes distinctes.
La deuxième consiste à lire « j’ai un mot de passe de connexion Windows » comme « le gestionnaire est immunisé contre un programme malveillant ». Ce mot de passe sert à empêcher un autre compte, et une copie du disque prise après extinction, d’ouvrir DPAPI. Si le programme tourne déjà après votre connexion, il utilise cet environnement utilisateur déjà déverrouillé. Le mot de passe de connexion reste nécessaire. Il répond à une autre porte.
La troisième consiste à lire « version supérieure à 127 » comme « mots de passe et cookies sont tous liés à l’application, et l’intérieur du processus ne voit plus rien ». Le point de départ officiel, ce sont les cookies. Les mots de passe sont prévus pour une extension ultérieure. Le chiffrement lié à l’application arrête l’ancien déballage depuis l’extérieur du navigateur. Une extension, ou du code déjà en cours d’exécution dans le processus, ne devient pas aveugle à cause de cette porte.
La quatrième consiste à lire « chaque site a un mot de passe différent » comme « si toute la liste est lue, ce n’est pas grave ». Des mots de passe distincts arrêtent ceci : la base d’un site fuit, et la même chaîne est rejouée contre votre messagerie et votre console cloud. Ils n’arrêtent pas le cas où un programme lit d’un coup toutes les entrées du gestionnaire. Les deux contrôles valent le coup. Ils ne couvrent pas la même défaillance.
Questions fréquentes
Le gestionnaire affiche « chiffré ». Les autres programmes de cette machine ne peuvent-ils plus lire ?
Non. « Chiffré » dit seulement que le champ sur le disque n’est pas en clair. Sur la génération DPAPI de Windows, Google écrit que la protection vise les autres utilisateurs et une copie du disque après extinction, pas un programme lancé avec l’identité de l’utilisateur connecté. Depuis Chrome 127, le chiffrement lié à l’application couvre d’abord les cookies : l’ancien déballage d’un programme extérieur échoue sur les données déjà migrées. L’intérieur du processus du navigateur lit encore. Le libellé « chiffré » à l’écran ne dit pas sur quelle génération se trouve le champ du mot de passe de cette machine.
Le chiffrement lié à l’application de Chrome 127 empêche-t-il aussi un programme malveillant d’ouvrir les mots de passe enregistrés ?
Non. La note du 30 juillet 2024 classe les mots de passe et les données de paiement parmi les objets à étendre dans des versions ultérieures. Le chiffrement lié à l’application resserre le droit de « l’utilisateur courant » vers « le programme du navigateur reconnu par un composant du système ». Cela explique pourquoi un programme extérieur qui ne fait que l’ancien déballage utilisateur échoue sur les données déjà migrées. Cela ne dit pas que le code à l’intérieur du processus est tenu dehors, ni que chaque mot de passe enregistré de votre navigateur a déjà fini sa migration.
Le rapport du 25 septembre prouve-t-il que n’importe quel programme peut déjà lire mes mots de passe Chrome ?
Non. Le rapport décrit une famille de programmes Windows qui lit les mots de passe enregistrés, les cartes, l’historique et les sessions de plusieurs navigateurs Chromium, ainsi que l’historique et les cookies de Firefox. Il indique que les champs de mot de passe utilisent AES-256-GCM, et que la clé passe par la protection des données au niveau de l’utilisateur. K7 ne donne pas de nombre de machines touchées, et ne présente pas cet échantillon comme un contournement du chiffrement lié à l’application. Pour savoir sur quelle génération se trouve votre navigateur, regardez la liste des enregistrements et si les mises à jour arrivent encore. Ne remplacez pas cela par le nom de l’algorithme cité dans l’article.
Après avoir changé le mot de passe du site, la session déjà enregistrée tombe-t-elle en même temps ?
Pas forcément. Changer le mot de passe invalide la prochaine connexion avec cette chaîne. Une session déjà émise demande souvent une déconnexion des autres sessions dans la liste des appareils du compte, ou une révocation par le site. Le même type de programme emporte la session et le mot de passe enregistré ensemble. Ne changer qu’un mot de passe, sans retirer les autres sessions, traite le mot de passe. Pas la session.
Comparer une fois « généré » et « pas enregistré », sans compte
Pour voir que « le mot de passe est apparu » et « le mot de passe est entré dans le gestionnaire du navigateur » ne sont pas la même étape, ouvrez le générateur de mots de passe de FastPwd. Aucune inscription. En mode aléatoire, gardez les 16 caractères par défaut et produisez une chaîne que vous pouvez jeter. Si le navigateur propose d’enregistrer, refusez. Revenez au gestionnaire : la liste ne doit pas afficher le site de test que vous venez d’utiliser. FastPwd n’a pas de coffre, et n’écrit pas à votre place dans la liste des mots de passe enregistrés.
La génération utilise crypto.getRandomValues. La longueur va de 6 à 128 caractères, 16 par défaut. En dessous de 8, un avertissement signale une sécurité plus faible. Le résultat n’est pas envoyé par défaut. Ouvrez les outils de développement, onglet Network, cochez la conservation du journal, et cherchez la chaîne entière dans les lignes de requête et dans les corps. Elle ne doit pas apparaître dans une requête métier. Cette étape prouve que, cette fois, le mot de passe n’a pas quitté l’onglet comme corps HTTP. Elle ne prouve pas qu’un programme malveillant local ne peut pas lire la page ou le presse-papiers. Si cet ordinateur n’est déjà plus fiable, générez et connectez-vous depuis un autre appareil.
Si vous voulez ensuite voir si une chaîne ressemble à un mot de passe faible très répandu, prenez une autre chaîne de test que vous pouvez jeter, et comparez-la dans le testeur de mot de passe. Le mot de passe testé n’est pas envoyé. Une absence de correspondance ne prouve pas qu’il n’a jamais été vu sur le web. Une correspondance dit seulement qu’il est trop courant. Ne collez pas dans le champ le vrai mot de passe que vous allez activer. N’exportez pas non plus tout le gestionnaire du navigateur pour le faire passer dans le testeur.
S’il faut remettre cette chaîne à une autre personne, une seule fois, ne la collez pas dans le corps d’un ticket qui finira dans un journal de serveur. Passez par le lien auto-destructeur : le serveur ne conserve que du texte chiffré, la clé se place après le # du lien, et la création comme la lecture se font sans compte. Ce canal répond à « comment remettre une fois ». Il ne répond pas à « comment rendre sûr un ancien mot de passe déjà enregistré dans le navigateur ». L’ancienne entrée se supprime encore dans le gestionnaire, et se remplace depuis un appareil auquel vous faites confiance.
Lectures liées
Pour chercher un canari dans Network et vérifier que « local, pas d’envoi » tient sur cette exécution, voir vérifier que le chiffrement local n’envoie pas le texte en clair. Changer un mot de passe ne retire pas une session déjà émise : on vous appelle pour mettre à jour votre passkey, et ce leurre vole la session, pas la Passkey. Une liste locale de mots faibles attrape les mots trop courants et ne remplace pas une recherche sur tout le web : ce qu’une liste locale de mots de passe faibles peut prouver.