Sécurité
La preuve que votre navigateur n'est pas un coffre-fort.
Chrome et Firefox enregistrent vos mots de passe — puis les remettent à n'importe quel programme s'exécutant sous votre identité. Ce n'est pas un bug. C'est la conception. Voici la preuve : une fois en langage clair, une fois en code.
La version en langage clair
Le « gestionnaire de mots de passe » de votre navigateur est protégé par un seul verrou : votre connexion à votre ordinateur. Une fois connecté à votre ordinateur portable, le navigateur peut lire instantanément chaque mot de passe enregistré — tout comme n'importe quel autre programme s'exécutant sur votre compte.
Un mauvais téléchargement. Un jeu de navigateur suspect. Un paquet empoisonné dans un projet que vous avez cloné. Au moment où il s'exécute — pendant que vous êtes connecté, comme vous l'êtes toujours — il lit tous les mots de passe que votre navigateur a enregistrés, dans le temps qu'il faut pour ouvrir un fichier. Il n'y a pas de mot de passe maître à casser, car il n'y a rien à casser : le navigateur a été conçu pour se déverrouiller automatiquement pour vous, et le logiciel malveillant demande simplement gentiment en tant que « vous ».
Ce n'est pas théorique. C'est la façon la plus courante dont les gens ordinaires perdent leurs comptes. Le logiciel malveillant a même un nom d'industrie ennuyeux — « info-stealers » — tant c'est banal. Vos mots de passe, vos cartes enregistrées, vos cookies de session : copiés et perdus avant que vous ne vous en rendiez compte.
La solution est simple à énoncer : vos mots de passe doivent être verrouillés avec quelque chose que le reste de votre ordinateur n'a pas — et ils ne devraient pas se trouver sur la machine du tout.
La version avec les preuves
Ne nous croyez pas sur parole. Chromium et Firefox sont open source, et le chemin de lecture est documenté, standard et court. Voici exactement où se trouvent les mots de passe et comment ils sont extraits.
Chrome (et tous les navigateurs Chromium)
Chrome stocke les identifiants dans une base de données SQLite — Login Data, table logins, colonne password_value — chiffrée avec AES-256-GCM. La clé AES se trouve dans Local State, « protégée » par le système d'exploitation : DPAPI sous Windows, le trousseau de connexion sous macOS, gnome-keyring/kwallet (ou en clair) sous Linux.
Lisez-le vous-même — le code est ouvert. Recherchez dans Chromium la constante qui identifie la clé encapsulée : kDPAPIKeyPrefix dans os_crypt. La clé est encapsulée DPAPI, étiquetée et stockée — puis désencapsulée avec un seul appel qui ne protège rien de vous :
const char kDPAPIKeyPrefix[] = "DPAPI";
CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
/*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);Pas de second secret, pas de mot de passe, pas d'invite. CryptUnprotectData renvoie la clé à tout processus s'exécutant dans votre session — ce qui correspond exactement au modèle de menace documenté par DPAPI : s'il s'exécute en tant que vous, il est vous. Le travail de l'attaquant se résume à trois lignes : lire la clé depuis Local State, la désencapsuler, déchiffrer AES-GCM chaque ligne dans Login Data. Les logiciels malveillants de type info-stealer font exactement cela depuis des années.
Le « chiffrement sur l'appareil » ne vous sauve pas non plus
La réponse de Google est un code PIN à 6 chiffres qui chiffre votre coffre-fort synchronisé. En mai 2026, des chercheurs de Phishu ont montré à quel point c'est fragile. Une fausse connexion Google convaincante — hameçonnage par l'intermédiaire de l'adversaire — capture la session et ce code PIN, et le code PIN est la clé principale de chaque mot de passe et passkey du compte synchronisé. Avec cela, un attaquant ajoute son propre appareil à votre « domaine de sécurité » Google et tout le coffre-fort se synchronise directement avec lui — prise de contrôle complète en une seule étape.
Le défaut de conception : Google permet à un appareil de se joindre avec le code PIN à 6 chiffres seul, sans approbation d'un appareil que vous possédez déjà.
Firefox
Firefox conserve les identifiants dans logins.json et la clé dans key4.db, déchiffrée par l'« Anneau Décodeur Secret » de NSS — également open source : security/nss/lib/pk11wrap/pk11sdr.c. Si vous définissez un Mot de passe principal, la clé est scellée avec celui-ci.
Par défaut, vous ne l'avez pas fait — donc la clé est scellée avec la chaîne vide, et une valeur « password-check » stockée confirme que le mot de passe vide la déchiffre. Copiez deux fichiers de votre profil (key4.db + logins.json), pointez NSS ou le script open source firepwd.py dessus, et ils se déchiffrent. Une serrure dont la clé est scotchée à la porte n'est pas une serrure.
Chaque magasin de mots de passe de navigateur a la même structure : le secret se trouve là où vous travaillez, déverrouillé par la session dans laquelle vous êtes déjà. Le chiffrement que le reste de votre propre ordinateur peut annuler ne vous protège pas de la menace qui vide réellement les comptes — le code s'exécutant en tant que vous.
Pourquoi Clavitor ne peut pas être lu de cette manière
Clavitor ne conserve pas votre coffre-fort sur la machine. Il n'y a pas de Login Data, pas de key4.db, pas de clé dans Local State — rien sur le disque qu'un processus s'exécutant en tant que vous puisse extraire.
La clé de déchiffrement n'est pas scellée avec votre connexion au système d'exploitation. Elle est dérivée d'une interaction matérielle — Touch ID, Face, ou une YubiKey — calculée dans le navigateur, utilisée pour une seule requête, puis supprimée. Un identifiant est récupéré via une API à portée limitée exactement lorsque vous le demandez, et jamais mis en cache. Les logiciels malveillants s'exécutant en tant que vous trouvent un placard vide.
C'est la différence entre « chiffré sur votre appareil » et « pas sur votre appareil du tout ».
Arrêtez de faire confiance au navigateur avec vos mots de passe.
L'extension Clavitor se remplit comme votre navigateur — et conserve le coffre-fort dans un endroit que votre ordinateur portable ne peut pas lire.