← Toutes les publications

Sécurité des mots de passe : pourquoi les gestionnaires intégrés aux navigateurs ne suffisent pas

Photo d’illustration

La plupart des navigateurs de bureau enregistrent les identifiants de connexion dans un fichier local, protégé uniquement par la session utilisateur du système d’exploitation. Cette conception, commune aux navigateurs basés sur Chromium — qui représentent plus de 70 % du marché des navigateurs de bureau —, expose les mots de passe à des programmes malveillants exécutés sous le même profil. Une alternative consiste à déplacer ces identifiants vers un coffre-fort logiciel qui exige une authentification distincte.

Le stockage des identifiants dans les navigateurs

Dans Chrome et Edge, les identifiants sont conservés dans une base SQLite nommée Login Data. Les entrées sont chiffrées, mais la clé de chiffrement n’est pas gérée par le navigateur lui-même. Elle est confiée au système d’exploitation : l’API Data Protection sous Windows, Keychain Services sous macOS. Le navigateur n’a donc jamais à demander de phrase secrète supplémentaire, car la session de bureau a déjà accordé l’accès.

L’API Data Protection authentifie la session ouverte, pas les applications individuellement. Tout exécutable lancé sous le même profil utilisateur hérite de cet accès. Google a introduit App-Bound Encryption dans Chrome courant 2024, une couche qui achemine les demandes de clé via un service privilégié ne répondant qu’aux binaires signés de Chrome. Des familles de logiciels dérobeurs d’informations comme Lumma, RedLine et VoidStealer ont contourné cette protection en quelques semaines. Au premier semestre 2025, ces programmes ont extrait 1,8 milliard d’identifiants depuis des navigateurs dans le monde.

Une fois la clé obtenue, le programme ouvre le fichier Login Data et lit les noms d’utilisateur, les URL et les mots de passe en clair. Le système d’exploitation ne détecte aucune anomalie : il accorde les mêmes permissions à tous les programmes du profil, et le remplissage automatique du navigateur repose précisément sur ce mécanisme.

Le fonctionnement d’un coffre-fort dédié

Un gestionnaire de mots de passe autonome comme Bitwarden ne se fie pas à la session système. Il exige un mot de passe principal connu de l’utilisateur seul, qui ne quitte pas l’appareil. Ce mot de passe subit des centaines de milliers de cycles de hachage gourmands en mémoire et en calcul, ce qui ralentit fortement le matériel spécialisé dans le cassage de mots de passe. Le résultat sert à chiffrer l’ensemble du coffre en AES-256 avant tout transfert vers les serveurs de l’éditeur.

Même en cas de violation de l’infrastructure cloud, les données restent chiffrées et indéchiffrables sans la clé. Lorsque le coffre est verrouillé, la clé de déchiffrement est effacée de la mémoire, privant ainsi un malware en arrière-plan de toute matière exploitable.

Le remplissage automatique intégré au navigateur, lui, s’exécute dès qu’une page termine son chargement, y compris dans des champs de formulaire invisibles. Des scripts publicitaires malveillants peuvent insérer des champs cachés dans des pages légitimes et récupérer ainsi les identifiants enregistrés sans aucune action de l’utilisateur. Bitwarden ne remplit une page que si le domaine correspond exactement à celui enregistré, et l’utilisateur peut exiger un raccourci clavier pour déclencher le remplissage.

Migrer ses identifiants en toute sécurité

La plupart des navigateurs Chromium permettent d’exporter les identifiants enregistrés au format CSV. Dans Chrome, il faut ouvrir la page de gestion des mots de passe, faire défiler jusqu’à l’option d’exportation et télécharger le fichier. Ce fichier contient les noms d’utilisateur, les adresses web et les mots de passe en texte lisible. Tant qu’il reste sur la machine, il doit être considéré comme une fuite de credentials potentielle.

Pour migrer vers un coffre-fort, la procédure est la suivante :

  1. Se connecter au coffre web du gestionnaire choisi, ouvrir les outils et sélectionner l’importation.
  2. Choisir le format correspondant au navigateur source et téléverser le fichier CSV exporté.
  3. Installer l’extension officielle du gestionnaire dans le navigateur, s’y connecter et tester quelques connexions pour vérifier que les entrées ont bien été transférées.
  4. Retourner dans les paramètres du navigateur, désactiver la proposition d’enregistrement des mots de passe et la connexion automatique.
  5. Supprimer définitivement les identifiants stockés dans la base du navigateur.
  6. Effacer le fichier CSV exporté et vider la corbeille.

Les étapes sont presque identiques dans Edge, Brave ou tout autre navigateur Chromium. Laisser d’anciens identifiants en place annule le bénéfice de la migration, puisqu’ils restent dans la même base vulnérable.

Ce qui est confirmé et ce qui reste incertain

Il est établi que les navigateurs Chromium stockent les identifiants dans une base locale dont la clé dépend de la session système, et que des malwares ont contourné les protections successives, y compris App-Bound Encryption. Les chiffres de 1,8 milliard d’identifiants dérobés au premier semestre 2025 et le taux de plus de 70 % de part de marché de Chromium sur le bureau sont des données factuelles issues du dossier.

En revanche, aucune information ne permet de savoir si des correctifs ultérieurs ont amélioré la robustesse d’App-Bound Encryption après les contournements signalés, ni si d’autres navigateurs non-Chromium présentent des vulnérabilités comparables. Le dossier ne précise pas non plus si des mesures systémiques sont envisagées par les éditeurs pour isoler davantage les bases d’identifiants. Ces points restent ouverts.

Illustration de l’article
Illustration de l’article
Illustration de l’article

En tant que Partenaire Amazon, je réalise un bénéfice sur les achats remplissant les conditions requises.