Après avoir changé le mot de passe et le code, qui peut encore entrer par la session IA du navigateur

Un collègue dit que le quota Claude vient d’être rechargé puis vidé, et qu’il n’a ouvert aucune fenêtre. L’entrée du gestionnaire de mots de passe date encore du mois dernier. Le téléphone n’a jamais sonné pour un code. Deux jours plus tard, la boîte de réception tient un message d’Anthropic : usage anormal, déconnexion forcée, moyen de paiement enregistré retiré. La lettre précise que Claude n’a pas été percé. Un infostealer sur cet ordinateur a recopié la session de connexion, en plus de tout ce qu’il ramasse déjà.

Le texte précédent traitait de quels mots masquer avant de coller un mot de passe dans ChatGPT ou Gemini : c’est le chemin après avoir mis du clair dans une invite, et la question de savoir si un interrupteur d’entraînement ou un lien de partage peut encore le lire. Ici, la question change. Une fois connecté, la preuve qui dit « c’est bien moi » reste dans des endroits que vous pouvez ouvrir — et qu’un programme local peut copier. S’il faut déplacer une clé, passez par un lien à usage unique de la forme s.html?id=…#…. Créer et lire se font sans compte. Les outils MyPassGen s’ouvrent sans inscription. Le reste de la page n’explique pas comment une famille de malware se propage. Il aligne des chiffres qu’Okta et Anthropic ont déjà publiés, et les lignes que vous voyez dans une liste de sessions.

Pourquoi le compte s’ouvre encore après un nouveau mot de passe

Un site ne redemande pas le mot de passe à chaque clic. Après une connexion réussie, le navigateur garde une session : un cookie, un JWT, et sur une application à page unique souvent un jeton dans localStorage ou sessionStorage. Les requêtes suivantes présentent cette preuve encore valable. Le serveur ne vérifie pas si vous savez réciter le mot de passe à cet instant. La note d’Okta Threat Intelligence du 9 septembre 2026, Signing in without actually signing in, appelle cette preuve une skeleton key, une clé passe-partout : déposez un jeton non expiré dans un autre navigateur et l’attaquant est déjà connecté. Le champ identifiant, le champ mot de passe et le défi MFA ne réapparaissent pas.

Ce n’est pas le même chemin que « quelqu’un a deviné le mot de passe ». Les passkeys et les clés matérielles relèvent la boîte de connexion. Okta écrit aussi qu’elles rendent plus difficiles les prises de compte par identifiant et mot de passe, et qu’elles n’arrêtent pas un jeton de session ou une clé API volés. Changer le mot de passe dans les paramètres ne concerne en général que la prochaine personne qui passe par la boîte de connexion. Les sessions déjà émises attendent une expiration, une révocation côté serveur, ou un coup de pied depuis la liste « appareils connectés ». Changer le mot de passe sans ouvrir cette liste, c’est changer la clé de la porte et laisser un badge encore valable sur la table.

L’article sur le presse-papiers couvrait un reste après Copier : le mot de passe a quitté le champ du générateur et est entré dans le presse-papiers système, voir après avoir copié un mot de passe, qui peut encore lire le presse-papiers. Un jeton de session quitte la page de connexion et entre dans le profil du navigateur et dans la mémoire. Les deux restes sont sur cet appareil. Ni l’un ni l’autre ne s’arrête parce que vous avez déjà cliqué sur Copier ou déjà réussi à vous connecter. Une fois la fenêtre privée fermée, les favoris et Téléchargements peuvent encore tenir une URL unique complète — ce chemin est dans une fois la fenêtre privée fermée, le mot de passe reste dans Téléchargements, les favoris et le presse-papiers. Les sessions vivent plus souvent dans le profil du quotidien. Fermer la fenêtre ne les révoque pas.

Okta : des jetons encore vivants dans 7 Go de journaux

Okta a analysé une archive gratuite postée sur un canal Telegram le 2 août 2026. Le fichier pesait environ 7 Go et couvrait 5 871 machines infectées dans 162 pays. Ils ont d’abord compté le matériel d’authentification, puis isolé le lot encore non expiré le jour de la publication — le lot qu’un acheteur rejouerait en premier.

Au format cookie Netscape, Google (Workspace et comptes grand public) avait 9 829 jetons d’authentification uniques ; 9 213 étaient encore valables le 2 août, sur 4 144 machines. Microsoft (Entra et grand public) donnait 2 491 / 1 763 / 1 753. Anthropic : 561 / 164 / 404. Cursor : 32 / 16 / 26. La même table listait aussi Amazon, Gamma, Notion, Character.ai, Poe.com et Pika AI. Google, Microsoft et Amazon passent par une porte d’authentification unique, donc ces comptes sont les jetons principaux que cette porte a émis, pas un classement de popularité de chaque produit.

Les JWT formaient une deuxième pile. Le jeu de données tenait 44 791 JWT uniques ; Okta en a marqué 555 comme probablement utilisés pour authentifier un service IA. Une recherche séparée a trouvé 2 937 JWE liés à l’authentification, la plupart émis par le NextAuth.js d’OpenAI. Sans la clé de déchiffrement, on ne lit pas le corps ; un jeton non expiré peut quand même être rejoué tel quel. Additionnés, 1 843 JWT et JWE étaient encore valables le 2 août. Okta écrit aussi que 17,7 % des corps de JWT portaient des données personnelles en clair — nom, téléphone ou e-mail. Après expiration du jeton, cette chaîne d’identité ne disparaît pas. Elle reste utile pour du hameçonnage.

Les jetons d’accès de courte durée tiennent souvent de quelques minutes à une heure, et un jeton de rafraîchissement HttpOnly les prolonge, pour empêcher un script de page de lire la moitié longue. Okta est explicite : le malware n’est pas lié par cette règle. Quand une application à page unique pose un JWT dans LocalStorage ou SessionStorage, la même copie le ramasse. Ils n’ont pas vu de sessions Okta volées dans cette archive. Ils ont en revanche écrit « réévaluer la session après un changement d’IP ou d’appareil » comme idée de détection côté entreprise. Un compte personnel n’a pas cette grille. Vous révoquez les lignes dans votre propre liste de sessions.

Anthropic : se déconnecter ne nettoie pas la machine

Fin août 2026, Anthropic a commencé à écrire à une partie des utilisateurs de Claude. BleepingComputer, SecurityWeek, Help Net Security, Malwarebytes et, en français, Les Numériques ont cité le même avis. La société écrit qu’un acteur a utilisé des infostealers courants pour voler des sessions Claude sur les ordinateurs d’autrui, puis s’en servir pour entrer dans le compte et brûler le quota. Si l’usage a semblé se recharger puis se vider alors que vous n’utilisiez pas Claude, c’était le chemin le plus probable. Ils ajoutent n’avoir aucune raison de croire que le malware soit lié à Claude, installé via Claude, ou lié à ce que vous avez fait dans Claude. Help Net Security reprend une phrase de plus : téléphones et tablettes ne semblaient pas pris dans cette vague.

SecurityWeek a listé les familles nommées : Vidar, Lumma, StealC, RedLine et Acreed sous Windows, et un plus petit ensemble d’Atomic Stealer (AMOS) sur Mac. Ce sont des voleurs généralistes. Ils arrivent en général avec un téléchargement non officiel ou une application malveillante, puis recopient les mots de passe enregistrés du navigateur, les cookies de connexion et d’autres identifiants locaux. Une session Claude n’était qu’un objet de cette récolte. Quelqu’un a ensuite commencé à extraire cet objet et à s’en servir.

Côté société, ils ont forcé la déconnexion des sessions touchées, retiré les moyens de paiement enregistrés et remboursé les frais classés comme non autorisés. La phrase qui compte dans l’avis est celle-ci : vous déconnecter de Claude arrête les sessions volées, mais n’enlève pas le malware. La machine est toujours là. La connexion suivante écrit une nouvelle session, que l’on peut recopier de la même façon. Leur ordre est : nettoyer l’appareil d’abord, puis changer le mot de passe de la boîte mail liée, activer la double authentification, et seulement ensuite remettre un moyen de paiement. Une déconnexion révoque le badge. Elle ne désinfecte pas l’ordinateur.

Clés API, LocalStorage et fichiers en clair : une autre couche

Un cookie de session couvre la connexion web. Une clé API couvre un programme qui appelle le modèle en votre nom. Okta a passé TruffleHog sur la même archive et trouvé 24 clés encore valables au moment de la publication, chez Google Gemini, OpenAI, Groq et OpenRouter. Ils citent trois factures nées de clés volées : près d’un million de dollars pour une organisation, 25 000 $ pour un architecte logiciel, et 600 000 $ de crédits chez une boutique de tests IA. Une clé dans un fichier de config ou une variable d’environnement est le plus rapide pour démarrer. C’est aussi le plus rapide, pour un programme local, de transformer votre quota en celui de quelqu’un d’autre. OpenAI, Anthropic et d’autres permettent de poser un plafond d’usage et une liste d’IP autorisées sur une clé. Sans ces grilles, une clé volée est déjà autorisée à vous facturer.

Un schéma plus stable est OAuth 2.0 : l’application reçoit un jeton d’accès de courte durée, le jeton de rafraîchissement reste dans le trousseau système ou un gestionnaire de mots de passe, et le périmètre reste aussi étroit que possible. Okta a mis « ne pas poser une clé API en clair dans un fichier de config ou une variable d’environnement » au même niveau qu’un mot de passe. Si un collègue a encore besoin de la clé, ne l’écrivez pas dans un fichier en clair qui va entrer dans Git ou un disque synchronisé — ce chemin est dans avant de déposer un fichier dans le cloud, qui peut lire le texte clair — et par quel canal envoyer la phrase secrète. Une URL unique complète dans un fichier de config reste une preuve d’identité : la tranche après # n’entre pas dans la ligne de requête HTTP, mais le fichier disque et le stockage objet tiennent encore la chaîne entière, comme dans quand on envoie un mot de passe une fois à un collègue, pourquoi la clé de déchiffrement va après # dans l’URL.

Les navigateurs ajoutent leurs propres freins. Okta mentionne l’App-Bound Encryption de Google en 2024, et les Device-Bound Session Credentials qui lient cryptographiquement une session à un appareil. Ils écrivent que l’ABE a vite vu des contournements, et que DBSC est encore tôt — les sites doivent l’implémenter côté serveur, et Chrome 145 pour Windows peut le supporter depuis mars 2026. Tant que le site que vous utilisez ne parle pas vraiment DBSC, ce qu’une personne peut contrôler reste : la liste de sessions montre-t-elle un appareil qui n’est pas le vôtre, et une clé dort-elle encore dans un fichier en clair ?

Ce que mot de passe, code et session bloquent vraiment

Prenez le même compte jetable et un profil de navigateur que vous contrôlez. Faites « changer seulement le mot de passe », « révoquer toutes les sessions », et « révoquer les sessions web, laisser le fichier de clé tranquille ». Les pages que vous pouvez encore ouvrir ne sont pas les mêmes. Le tableau est écrit depuis des portes que vous cliquez, pas depuis des noms marketing.

Ne mélangez pas la cinquième ligne avec les quatre premières. Écrire une s.html?id=…#… complète dans un dépôt ou un chat laisse encore une preuve dans le fichier local et dans un journal d’infostealer. L’hôte qui range le texte chiffré ne voit pas la clé. Séparez l’identifiant et la clé, et une recherche plein texte ne trouve plus un lien qui s’ouvre. Traitez un lien complet comme le mot de passe lui-même.

Vérifier sur place

Les étapes ci-dessous ne dépendent d’aucune promesse de marque. Utilisez un compte jetable et un mot de passe de test qui ne se connectera jamais à un vrai travail, par exemple orange-lake-7. Ne vous entraînez pas avec un mot de passe principal en service, une clé API de production ou une URL unique vivante.

1. Inscrivez-vous ou connectez-vous à un compte IA ou Google jetable dans votre navigateur du quotidien, et restez connecté. Ouvrez la page appareils connectés, sessions ou sécurité de ce service et notez la ligne courante. Connectez-vous à nouveau depuis un second navigateur ou une fenêtre de navigation privée. Actualisez la première fenêtre : vous devriez voir deux lignes. Révoquez celle que vous n’utilisez pas. Actualisez la seconde fenêtre : elle doit retomber sur la boîte de connexion. Cette étape contrôle si la liste de sessions peut vraiment tuer un badge. Ce n’est pas un test de malware.
2. Restez connecté dans la première fenêtre. Changez seulement le mot de passe. Ne cliquez pas sur « se déconnecter de tous les appareils ». Regardez la seconde fenêtre. Certains produits jettent toutes les sessions d’un coup. D’autres ne retirent que l’ancien mot de passe et laissent les sessions ouvertes en vie. Notez ce que vous voyez. N’utilisez pas cette observation pour deviner tous les produits. Fiez-vous à la page que vous venez d’actualiser.
3. Si un compte Google est la porte de Gemini ou de Workspace : ouvrez l’activité des appareils du compte Google et cherchez un lieu ou un navigateur qui n’est pas le vôtre. Google et Microsoft étaient les deux plus grandes colonnes de la table Okta, parce qu’un seul jeton SSO ouvre une file d’applications derrière. Après révocation d’un inconnu, vérifiez si Gemini ou le courrier redemande une connexion.
4. Si vous utilisez Claude, ChatGPT ou Cursor : dans les paramètres du compte, trouvez les sessions, les clients connectés ou la liste des clés API. Révoquez ce que vous pouvez révoquer. Supprimez les clés que vous pouvez supprimer, puis en créez de nouvelles. L’avis d’Anthropic a déjà dit qu’être déconnecté du site n’est pas la même chose qu’un ordinateur propre. Savoir si cette machine a un voleur est une question pour vos propres outils de sécurité système. MyPassGen ne scannera pas le disque à votre place.
5. Cherchez sur cette machine la chaîne de clé de test : le dossier projet, .env, l’historique local de l’éditeur, l’historique du terminal. Une fois les sessions web parties, un fichier en clair est encore une autre copie. Le traitement est dans l’article sur le chiffrement de fichiers. Ne collez pas dans un chat une clé de production que vous venez de trouver.
6. Créez un lien MyPassGen à usage unique avec la même phrase de test, expiration 24 heures, lectures laissées à 1. Dans le chat ou un ticket, collez seulement la partie avant le dièse, s.html?id=…. Dites la clé au téléphone ou en face. S’ouvre sans compte. Avec seulement l’identifiant, le destinataire doit voir un lien incomplet ; les deux moitiés sont nécessaires pour déchiffrer. Après lecture, écrasez le presse-papiers. Ne stockez pas une adresse qui a encore # dans un profil de navigateur qui se synchronise.

Sur un compte d’entreprise, ajoutez une demi-étape : demandez si le SSO forcé est allumé, s’il existe une détection de risque de session, et si les clés API ont un plafond d’usage et une liste d’IP. MyPassGen ne vous dira pas si une passerelle donnée a stocké une autre copie. Fiez-vous aux fenêtres que vous venez d’ouvrir.

S’il faut transmettre une clé, séparez les canaux

Pour une remise en tête-à-tête que l’autre personne peut ouvrir tout de suite, n’écrivez pas une clé API en clair qui va entrer dans un dépôt, un disque synchronisé ou une archive de chat. Générez le mot de passe sur cet appareil, puis enveloppez-le dans un lien à usage unique. Le générateur de mot de passe MyPassGen propose un mode aléatoire de 6 à 128 caractères, 16 par défaut, et prévient sous 8. Il s’ouvre sans compte. Le résultat n’est pas envoyé comme donnée métier. À la création, le navigateur chiffre avec AES-256-GCM. Une note tient au plus 32 Ko. Les lectures valent 1 par défaut et plafonnent à 10. L’expiration peut être 1 heure, 24 heures, 7 jours, ou seulement au compteur, sans TTL. Le serveur ne range que le texte chiffré.

Quand un dépôt ou un ticket a encore besoin d’un point d’entrée, séparez le canal. Le fichier porte seulement le responsable, l’identifiant, et la phrase « clé par téléphone ». Un appel, une remise en personne ou un autre compte de messagerie porte seulement la tranche après #. Aucune moitié ne déchiffre seule. C’est un usage, pas un défaut produit. La page de création émet encore un lien complet, commode pour un envoi en tête-à-tête. Sur un canal qui dessine des cartes d’aperçu, lancez d’abord un lien de test et voyez si l’aperçu compte une lecture, comme dans si vous collez un lien à usage unique dans Slack ou WeChat, l’aperçu le brûle-t-il d’abord.

Un paquet de clés ou un export de plus de 32 Ko n’a pas sa place sur un lien texte à usage unique. Passez par la boîte de chiffrement de fichiers : AES-256-GCM en flux dans le navigateur, un fichier jusqu’à 5 Go, sortie .lock / .enc, phrase secrète envoyée à part. Chiffrez d’abord sur cet appareil, puis synchronisez ; l’autre côté ne doit voir que du chiffré. Pousser un .env non chiffré vers un disque, ou le laisser à une extension de navigateur, est le même type de problème que laisser un cookie de session à un programme local : la preuve qui dit « c’est bien moi » a quitté la fenêtre où vous pensiez qu’elle vivait.

Une fois que vous avez contrôlé « changer seulement le mot de passe jette-t-il la seconde session » et « après révocation d’une ligne, l’autre fenêtre retombe-t-elle sur la boîte de connexion », vous pouvez répondre à la question de l’article : le mot de passe a changé, la double authentification est allumée, et une session IA encore valable ou une clé API en clair peut encore laisser quelqu’un d’autre entrer. Anthropic a déconnecté les anciens badges. Okta a compté les jetons encore vivants le jour de la publication. Une liste de sessions est un endroit où contrôler. C’est un mauvais endroit pour supposer « j’ai déjà changé le mot de passe, donc c’est fini ».

Questions fréquentes

J’ai changé le mot de passe. L’autre personne peut-elle encore entrer ?

Elle ne peut plus utiliser l’ancien mot de passe à la boîte de connexion. Ce n’est pas la même chose que toutes les sessions déjà émises qui meurent d’un coup. Fiez-vous à la liste que vous actualisez sous les appareils connectés. Okta décrit le rejeu d’un jeton non expiré comme un contournement du mot de passe et de la MFA. Révoquez les sessions, puis changez le mot de passe. Faites les deux. Ne faites pas seulement l’étape dont vous vous souvenez.

La MFA ou une passkey remplacent-elles un lien à usage unique ?

Non. La MFA et une passkey gardent la boîte de connexion. Un jeton de session prouve « déjà connecté ». L’avis d’Anthropic a aussi formulé le problème comme des sessions volées, pas des mots de passe devinés. Pour contrôler « le serveur a-t-il vu autre chose que du chiffré », utilisez un lien à usage unique et Réseau. Ne substituez pas « j’ai allumé un second facteur ».

En quoi une URL unique complète dans .env est-elle mieux que la clé API elle-même ?

Les journaux serveur et les aperçus HTML seuls ne voient en général pas la clé après #. Le fichier local, l’historique de l’éditeur et un journal d’infostealer peuvent encore tenir l’URL entière. Qui la copie peut l’ouvrir avant qu’elle ne brûle. Plus sûr : ne mettez que l’identifiant dans le fichier ; envoyez la clé sur un autre canal. La clé elle-même a encore besoin d’un chemin de révocation et d’un plafond d’usage.

Faut-il un compte pour créer et lire ? Si je me trompe de canal, le support peut-il récupérer ?

Aucune inscription. Créer et lire sont publics pour un visiteur. Une fois le texte chiffré brûlé par le compteur ou l’expiration, il n’y a pas de sauvegarde en clair côté serveur, ni de boîte support qui puisse le récupérer. Générez un nouveau mot de passe et un nouveau lien. N’actualisez pas la même URL pour voir si elle revient.