Sur un PC Windows, les mots de passe ne résident pas dans un emplacement unique. Ils se répartissent entre plusieurs couches du système et des navigateurs, chacune appliquant ses propres mécanismes de chiffrement et de contrôle d’accès. Comprendre cette architecture permet d’évaluer réellement le niveau d’exposition d’une machine.
Base SAM et secrets LSA : le stockage système des mots de passe Windows
Les mots de passe des comptes locaux Windows sont conservés dans la base Security Accounts Manager (SAM), un fichier situé dans C:\Windows\System32\config\SAM. Ce fichier ne contient jamais les mots de passe en clair : Windows y inscrit des valeurs hachées, produites par l’algorithme NT Hash (MD4 appliqué à l’entrée Unicode).
A lire en complément : Quelle est la meilleure application de sécurité ?
Le fichier SAM est verrouillé en exclusivité par le noyau tant que le système tourne. Aucun processus utilisateur ne peut l’ouvrir directement. Un attaquant disposant d’un accès physique peut toutefois démarrer depuis un support externe ou extraire une copie via le Volume Shadow Copy Service.
Les comptes de service et les identifiants de domaine mis en cache passent par un autre mécanisme : les secrets LSA, stockés dans le registre sous HKEY_LOCAL_MACHINE\SECURITY. Ces secrets sont chiffrés avec une clé dérivée de la clé de démarrage du système (SYSKEY). En environnement Active Directory, les condensats en cache (cached domain credentials) permettent l’ouverture de session hors connexion, mais augmentent la surface d’attaque si le disque est compromis.
A lire aussi : Quelles informations sont exemptées du RGPD ?
Gestionnaire d’identifiants Windows : mots de passe web et réseau
Le Gestionnaire d’identifiants (Credential Manager) centralise un second ensemble de mots de passe : ceux enregistrés pour les partages réseau, les connexions Bureau à distance et certains sites web consultés via Internet Explorer ou Edge en mode legacy.
Deux coffres coexistent :
- Le coffre « Identifiants Web » conserve les couples utilisateur/mot de passe saisis dans les navigateurs Microsoft historiques. Leur déchiffrement repose sur DPAPI (Data Protection API), liée au mot de passe de session de l’utilisateur.
- Le coffre « Identifiants Windows » stocke les authentifications réseau (SMB, RDP, WMI). Ces entrées sont également protégées par DPAPI et ne sont lisibles que dans le contexte de la session qui les a créées.
- Un troisième type, les identifiants génériques, peut apparaître lorsqu’une application tierce utilise l’API CredWrite pour persister un jeton ou un mot de passe applicatif.
Accéder au Gestionnaire d’identifiants passe par le Panneau de configuration ou par la commande cmdkey /list dans l’invite de commande. L’affichage d’un mot de passe web exige la saisie du mot de passe ou du code PIN de la session active.
Navigateurs Chrome, Edge Chromium et Firefox : emplacements des mots de passe sur PC
Les navigateurs modernes maintiennent leur propre base, distincte du Gestionnaire d’identifiants Windows.
Chrome et Edge Chromium
Chrome stocke les mots de passe enregistrés dans une base SQLite nommée Login Data, située dans le profil utilisateur (sous AppData\Local\Google\Chrome\User Data\Default). Les valeurs sont chiffrées via DPAPI, ce qui les lie à la session Windows. Edge Chromium, basé sur le même moteur, adopte une structure identique dans son propre répertoire de profil.
Lorsque la synchronisation est activée, Chrome copie ces identifiants dans le Gestionnaire de mots de passe Google, associé au compte Google de l’utilisateur. Les mots de passe deviennent alors accessibles depuis n’importe quel appareil connecté au même compte. La distinction entre stockage local et stockage synchronisé dans le cloud est souvent négligée dans les guides centrés sur les chemins de fichiers Windows.
Firefox
Firefox utilise un mécanisme indépendant. Les identifiants sont conservés dans les fichiers logins.json et key4.db du profil utilisateur. Le chiffrement repose sur NSS (Network Security Services) et non sur DPAPI. Si un mot de passe principal (Primary Password) est configuré, il sert de clé de déchiffrement. Sans ce mot de passe principal, toute personne ayant accès à la session peut lire les identifiants en clair depuis les paramètres du navigateur.
Passkeys et fin progressive du mot de passe stocké sur PC
Le modèle du « mot de passe enregistré quelque part sur le disque » recule face aux passkeys. Une passkey repose sur une paire de clés cryptographiques asymétriques : le site conserve la clé publique, la clé privée reste sur l’appareil ou dans un gestionnaire de clés synchronisé. Il n’existe donc aucun mot de passe réutilisable à retrouver dans le navigateur.
Le NIST, dans la révision SP 800-63-4 finalisée en juillet 2025, distingue désormais les passkeys synchronisées (transférables entre appareils via un cloud chiffré) des clés liées à un appareil unique. Cette distinction a des conséquences sur le niveau d’assurance attribué à chaque méthode d’authentification.
Autre changement notable issu de cette même révision : la rotation périodique des mots de passe n’est plus recommandée comme bonne pratique générale. Le NIST privilégie la détection de compromission et le recours à des authentificateurs résistants au phishing, dont les passkeys font partie.
Points de faiblesse réels : ce qui expose les mots de passe stockés
L’emplacement du fichier n’est qu’une partie du problème. La vulnérabilité effective dépend de la chaîne complète :
- DPAPI protège les coffres Chrome, Edge et le Gestionnaire d’identifiants, mais sa sécurité s’effondre si le mot de passe de session Windows est faible ou si un malware tourne dans le contexte de l’utilisateur connecté.
- Le fichier SAM résiste à l’extraction à chaud, mais un accès physique au disque (ou une copie shadow) suffit à récupérer les condensats pour une attaque hors ligne.
- Firefox sans mot de passe principal offre une protection quasi nulle : la base
logins.jsonse déchiffre trivialement avec la clé stockée danskey4.dbaccessible au même utilisateur. - Les mécanismes de récupération cloud (compte Google, compte Microsoft) deviennent eux-mêmes un vecteur si l’authentification du compte cloud repose sur un simple mot de passe sans second facteur.
Le maillon le plus fragile reste souvent le mot de passe de session Windows lui-même. C’est lui qui, via DPAPI, protège la majorité des secrets locaux. Un mot de passe de session robuste, couplé à un chiffrement intégral du disque (BitLocker avec TPM), neutralise la plupart des scénarios d’extraction physique et logique.
