S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 31 octobre 2016
N° CERTFR-2016-ACT-044
Affaire suivie par: CERT-FR
le 31 octobre 2016

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité CERTFR-2016-ACT-044

Gestion du document

Référence CERTFR-2016-ACT-044
Titre Bulletin d’actualité CERTFR-2016-ACT-044
Date de la première version 31 octobre 2016
Date de la dernière version 31 octobre 2016
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 – Réflexions sur les politiques de mot de passe

Introduction

En mai 2016, Microsoft a publié un document intitulé « Microsoft Password Guidance » (cf. Documentation) qui étudie la gestion des mots de passe : il fournit ainsi diverses recommandations et décrit plusieurs a priori répandus et erreurs pouvant être commises.

Réflexions sur les politiques de mot de passe

Une partie du document rappelle les recommandations régulièrement formulées concernant la gestion des mots de passe, parmi lesquelles on peut citer :
  • avoir des mots de passe uniques par application (Active Directory, messagerie, etc.) et par usage (professionnel, personnel) ;
  • imposer une longueur minimale (8 caractères sont recommandés) ;
  • éviter l’utilisation de mots de passe prédictibles (mots de passe communs ou par défaut, reprise du nom ou de la date de naissance, etc.) ;
  • sécuriser l’environnement (mise à jour des systèmes et des programmes, sensibilisation des utilisateurs au phishing, etc.).

En plus de ces recommandations de base, le document décrit des recommandations plus avancées et plus rarement mises en œuvre :

  • mettre en place une authentification multifacteur (appelée également MFA pour multifactor authentication) ;
  • mettre en place une surveillance afin d’être en capacité à détecter une utilisation frauduleuse des mots de passe :
    • attaque distante en force brute,
    • changement de l’origine de l’authentification (détection d’authentification depuis un autre système, etc.),
    • horaires suspects (nuit, week-end).

Le document aborde enfin plusieurs erreurs régulièrement commises dans la gestion des mots de passe et couramment reprises dans des PSSI. Ces erreurs prennent la forme de recommandations contraignantes alors qu’elles n’apportent pas de réel gain de sécurité. Ces erreurs sont :

  • exiger des mots de passe très longs (plus de 12 caractères) : si une telle mesure est imposée, il est difficile pour un utilisateur de retenir son mot de passe si celui-ci est vraiment aléatoire. Le mot de passe prend alors la forme d’une succession de mots plus ou moins prévisible (t5f75dzp est un meilleur mot de passe que monbeausoleil) ;
  • exiger l’utilisation de caractères spéciaux : lorsqu’un utilisateur doit utiliser des caractères spéciaux, il se contente, le plus souvent, de substituer les chiffres et les lettres par des caractères spéciaux avec un procédé plus ou moins prédictible (a remplacé par @, s par $, 1 par !, etc.) ;
    NB : Les esprits plus matheux font d’ailleurs souvent remarquer qu’imposer une classe de caractères obligatoires réduit l’espace possible des mots de passe, ce qui est contre-intuitif.
  • imposer un renouvellement trop fréquent des mots de passe (par exemple tous les 2 mois) : le risque, lorsqu’un utilisateur doit renouveler trop souvent son mot de passe, est de voir apparaître un compteur dans le mot de passe. Ainsi, en connaissant les anciens mots de passe, il devient très aisé de deviner celui en cours (exemple : feEgIsR#c1, feEgIsR#c2, feEgIsR#c3, etc.).

On peut également ajouter la mesure consistant à verrouiller automatiquement un compte utilisateur suite à un nombre trop élevé de tentatives d’authentification distante avec un mot de passe erroné. Si cette mesure permet d’éviter les attaques en force brute, elle permet également de réaliser facilement un déni de service. Cette mesure, généralement appliquée dans les annuaires Active Directory, peut être la cause d’un déni de service complet et facilement réalisable par un attaquant.

Évidemment, sorties de leur contexte, ces erreurs font polémiques. Pour écrire une bonne politique de mot de passe, il faut considérer avec attention le contexte d’utilisation. Nous allons ci-dessous étudier deux contextes très courants : celui d’une application Web avec une authentification par formulaire et celui d’un annuaire Active Directory.

Authentifications en environnement Web

Dans le cadre d’une authentification Web, il est aisé de mettre en œuvre une authentification multifacteur. Cela consiste à disposer d’un moyen supplémentaire, en plus d’un mot de passe, pour authentifier l’utilisateur.

Cela peut prendre la forme d’un jeton générant des numéros uniques, d’un code à saisir après avoir été envoyé par SMS sur le téléphone de l’utilisateur ou de services tiers disponibles sur Internet.
NB : Il faut noter qu’avec la généralisation des téléphones intelligents, déployer une solution d’envoi de code par SMS est peu coûteux.

L’objectif de l’authentification multifacteur est de maintenir la confiance accordée au mot de passe de l’utilisateur. Ainsi, l’authentification multifacteur peut être déclenchée périodiquement, en cas d’activité suspecte sur le compte (tentative d’authentification échouée, horaires suspects, etc.) ou être imposée de manière permanente.

Toujours dans le cadre d’une authentification Web, le mot de passe est généralement transmis en clair du client au serveur via un formulaire HTML et transmis en HTTPS. Il est alors possible de réaliser des tests avancés sur la prédictibilité du mot de passe afin de rejeter ceux qui ne seraient pas conformes.
NB : En « clair » signifie ici que le serveur récupère le mot de passe de l’utilisateur et non pas l’empreinte ou une réponse à un défi/réponse. Évidemment, les échanges réseau doivent être protégés par TLS.

Authentifications en environnement Active Directory

La situation est différente dans le cadre d’un Active Directory. Si l’authentification repose également sur un mot de passe, les contrôleurs de domaine n’en connaissent que l’empreinte et l’authentification ne repose jamais directement sur le mot de passe en clair. Par exemple, l’authentification distante est réalisée au moyen d’un protocole basé sur des défis/réponses NTLM ou sur des tickets Kerberos. Cependant, si un attaquant réussit à capturer ce type d’échange, il est alors en mesure d’effectuer des attaques hors ligne pour retrouver le mot de passe (attaque par dictionnaire, force brute, chaînes de Markoff, etc.). Il est alors primordial d’imposer une complexité au mot de passe afin de résister suffisamment longtemps aux attaques avant son renouvellement.

Avec un Active Directory, il est possible d’utiliser une carte à puce pour authentifier l’utilisateur. Cette méthode apporte un facteur supplémentaire qui peut être forcé utilisateur par utilisateur (option « Une carte à puce est nécessaire pour ouvrir une session interactive »). Cette solution n’est cependant pleinement efficace que si l’authentification NTLM est désactivée, ce qui impose que l’utilisateur soit membre du groupe « Protected Users ». Malheureusement, beaucoup d’applications ne fonctionnent plus si Kerberos est imposé. Cette solution est donc, pour le moment, principalement destinée aux groupes d’administration les plus privilégiés de l’Active Directory (Administrateurs du domaine).

Un point extrêmement important concernant les environnements Active Directory est de pouvoir effectuer des attaques de type « pass-the-hash » ou « pass-the-key ».
NB : Ces attaques n’utilisent pas de vulnérabilités liées aux protocoles NTLM ou Kerberos, mais des principes inhérents aux formes d’authentification mises en œuvre.
Ces attaques consistent à s’authentifier à distance uniquement avec l’empreinte d’un mot de passe ou avec une clé Kerberos sans qu’il soit nécessaire de la casser, c’est-à-dire de retrouver le mot de passe d’origine. En général, les empreintes ou clés sont récupérées dans des fichiers de sauvegarde, dans la mémoire d’un système quand celui-ci est compromis ou dans la base Active Directory lorsqu’un contrôleur de domaine est compromis ou qu’un attaquant récupère des droits d’administration du domaine. En disposant d’une empreinte ou d’une clé, il est donc possible de s’authentifier à distance, quelle que soit la complexité du mot de passe. Contre les attaques de ce type, les politiques de complexité de mot de passe n’apportent aucune sécurité et la protection des systèmes et des authentifiants devient primordiale (mise à jour, cloisonnement des droits d’administration, etc.).

Les dernières versions de Windows apportent de nouveaux mécanismes qui améliorent la sécurité de l’authentification en environnement Active Directory (silos d’authentification, Microsoft Hello ou Microsoft Password for Work). Ceux-ci nécessitant des versions récentes de Windows, il faudra attendre la migration des parcs avant de pouvoir en profiter.

Enfin, l’Active Directory ne permet pas nativement la mise en place d’une authentification multifacteur. Cela impose de passer par des solutions tierces, plus ou moins fiables.

Conclusion

Le document publié par Microsoft doit permettre de se poser les bonnes questions concernant les politiques de mots de passe, car elles sont plus complexes qu’il n’y paraît à écrire. En particulier, les politiques doivent être adaptées à chaque contexte d’utilisation.

Recommandations

En conclusion de cette analyse, le CERT-FR formule plusieurs recommandations décrites ci-dessous.

Recommandations génériques

  • Sécuriser le contexte d’utilisation des mots de passe (mise à jour des systèmes, cloisonnement, durcissement des systèmes, etc.)
  • Mettre une surveillance des authentifications permettant, en particulier, de détecter :
    • un nombre trop important d’authentifications échouées
    • des changements dans les périodes d’authentification (nuit, week-end)
    • des changements dans les origines des authentifications
  • S’assurer que le mot de passe choisi ne soit pas prédictible : pas celui par défaut, non lié à l’utilisateur (nom, date de naissance, etc.), pas un nom commun ou propre, etc.
  • Désactiver les comptes qui ont des périodes d’inactivité trop élevées
  • Imposer un renouvellement des mots de passe avec une période définie en fonction du contexte et de la mise en œuvre des autres recommandations (donc de 6 mois à plusieurs années)
  • Être toujours capable, à tout moment, de pouvoir changer tous les mots de passe d’un annuaire d’authentification (y compris l’ensemble des mots de passe des comptes de service)

Recommandations pour les applications Web

  • Mettre en place une authentification multifacteur activable périodiquement ou de manière permanente
  • Ne pas stocker le mot de passe en clair sur le serveur et ne sauvegarder qu’un condensat du mot de passe
  • Pour le calcul du condensat, privilégier des algorithmes adaptés (par exemple PBKDF#2) et l’utilisation d’une graine
  • Sécuriser le transport du mot de passe en utilisant TLS (version 1.2 recommandée)
  • Permettre à l’utilisateur de pouvoir accéder à l’historique de l’utilisation de son compte, afficher systématiquement en page d’accueil les paramètres de la dernière connexion et le sensibiliser à détecter les anomalies (horaires suspects, changement d’adresse IP)

Recommandations pour Active Directory

  • N’avoir aucun compte qui n’expire jamais (attribut DONT_EXPIRE)
  • Pour les comptes de service :
    • disposer pour chaque compte de service d’un document décrivant l’utilisation du compte et la procédure de changement du mot de passe associé
    • privilégier l’utilisation des comptes de service gérés (locaux ou de groupe) afin que le mot de passe soit géré par les systèmes et automatiquement changé
  • Désactiver les variantes historiques du protocole NTLM pour n’utiliser que NTLMv2
  • Protéger au maximum les contrôleurs de domaine, les postes d’administration ainsi que tous les systèmes qui manipulent les comptes d’administration du domaine
  • Afficher, après chaque authentification interactive d’un utilisateur, les paramètres de sa dernière authentification et le sensibiliser à détecter les anomalies (horaires suspects et échecs) (option GPO : Modèles d’administration, Composants Windows, Options d’ouverture de session Windows, Afficher les informations sur les ouvertures de session précédentes au cours d’une ouverture de session utilisateur)
  • Mettre les groupes d’utilisateurs les plus sensibles dans le groupe « Protected Users »
  • Mettre en place une centralisation des journaux Windows et surveiller les évènements liés à l’utilisation des mots de passe :
    • 4625(F): An account failed to log on
    • 4624(S): An account was successfully logged on
    • 4740(S): A user account was locked out
    • 4768(S, F): A Kerberos authentication ticket (TGT) was requested
    • 4769(S, F): A Kerberos service ticket was requested

Enfin, concernant le choix des mots de passe des utilisateurs, ceux-ci doivent faire au minimum 8 caractères et être distincts par application, non prédictibles et renouvelables à tout moment.

Dans le cas d’un Active Directory, du fait de pouvoir récupérer des échanges réseau contenant des éléments d’authentification directement liés au mot de passe (réponse NTLM ou message Kerberos Authentication Service), la longueur minimale doit être portée à 10 caractères, sauf pour les membres du groupe « Protected Users » qui, par les protections apportées, peuvent disposer de mot de passe de 8 caractères.
NB : Ce groupe apporte deux protections : d’une part le protocole NTLM ne peut plus être utilisé et, d’autre part, avec Kerberos, seul le chiffrement AES est autorisé. Dans ce cas, les clés AES sont dérivées depuis le mot de passe via un mécanisme PBKDF2 avec, par défaut, 4096 itérations, ce qui rend les attaques sur les mots de passe particulièrement lentes.

Dans tous les cas, des règles plus strictes peuvent être appliquées aux mots de passe des administrateurs et des comptes sensibles.

Documentation

Rappel des avis émis

Dans la période du 24 au 30 octobre 2016, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 31 octobre 2016
    version initiale.