Mot de passe Windows

Un développeur senior de Microsoft (Steve Syfuhs) tient un blog très intéressant (et forcément pertinent) sur la sécurité de Windows, en décrivant le fonctionnement de plusieurs fonctionnalités de sécurité, dont le mot de passe (sous Windows). Je vais tenter un résumé-traduction.

Concepts principaux

On regardera ici l’authentification interactive, puisqu’il y a saisie de texte (le mot de passe). Il existe bien sûr d’autres méthodes interactives, et même des non-interactives. On peut en avoir un aperçu dans la base de registre dans :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers.

Ces méthodes sont nommées authentication packages. En gros ça fonctionne comme çà :

interactive authentication

GINA signifie Graphical Identification and Authentication dynamic-link library. C’est une DLL chargée par winlogon, la brique de base de tout ça.

Au démarrage du système, ainsi que lors de l’appui sur la (fameuse) séquence CTRL+ALT+DEL, un signal spécial appelé SAS (Secure Attention Sequence) indique au système d’exploitation qu’on va demander une séquence de connexion (login) ou le déconnexion (logout).

winlogon reçoit ce signal et charge la librairie GINA pour récupérer le mot de passe, laquelle appelle la fonction LsaLogonUser (LSA étant la Local Security Authority, qui est un sous-système de Windows chargé d’authentifier et de connecter les utilisateurs locaux au système), et qui va évaluer les informations d’authentification à partir des méthodes connues du système (les authentication packages vus plus haut).

Ca fait un peu poupée russe, mais bon.

Le mot de passe de référence, il est où ?

Quelques réglages utiles

Pas de mot de passe en clair

Le plus basique : interdire le stockage en clair des mots de passe. Dans HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest, la valeur UseLogonCredential  doit être à 0. Toute modification devrait en outre être signifiée à l’administrateur…

Protéger le service LSA

Le service Local Security Authority Subsystem Service, qui est critique, peut également être protégé dans les versions Pro et Ent de Windows. La procédure est ici (site Microsoft). Attention à cette manipulation car, si je comprends bien, elle empêche certains usages (comme le développement ou le débogage de plugins pour LSA).

Gérer le cache des informations de connexion

Il est géré dans la base de registres Windows dans HKEY_LOCAL_MACHINE\SECURITY\Cache, mais je n’ai pas pu vérifier par moi-même. Reportez-vous à l’article original de csoonline.com.

Bien paramétrer le gestionnaire d’authentification

Cela va de soi, le conseil est assez générique, et il sera difficile d’aller plus loin sans faire le tour des solutions.

Note : Credential Guard, une fonctionnalité fort utile sous Windows, ne semble disponible que dans les versions Entreprise. Elle semble pourtant empêcher des outils tels que mimikatz de fonctionner…

Sources de ce paragraphe

Local ou Kerberos ?

Voir aussi

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *