Les mots de passe constituent aujourd’hui un moyen d’authentification universel, parce que simple à configurer coté serveur, simple à utiliser depuis n’importe quel terminal, et simple à comprendre pour l’utilisateur. Néanmoins, ils sont tout aussi simples à voler ou à deviner pour un attaquant…

Face à ce risque, il est nécessaire de mettre en place des préconisations, si possible adossées à des mesures techniques pour s’assurer qu’elles soient effectivement mises en œuvre. Néanmoins, comme toutes contraintes liées à la sécurité, celles-ci doivent être adaptées au contexte, en particulier de leur impact sur l’utilisabilité, sous peine d’être peu suivies, ou contournées. En particulier dans la communauté Enseignement Supérieur et Recherche, où l’argument d’autorité manque parfois d’efficacité…

Voici donc quelques conseils pour limiter les risques de sécurité associés aux mots de passe, vu sous l’angle du meilleur compromis entre gain de sécurité, et impact sur l’utilisation. Plus qu’une liste de préconisations sur étagère, il s’agit surtout d’une présentation de différents points de vue sur quelques mesures simples, de façon à aider un responsable à bâtir sa propre politique.

 

 

ROBUSTESSE

Les attaques par force brute consistent à énumérer l’ensemble des mots de passes possibles. La contre-mesure élémentaire consiste à augmenter la taille de cet ensemble, en jouant sur deux paramètres possibles:

  • la longueur du mot de passe
  • la complexité du mot de passe, correspondant au nombre de symboles utilisables

Pendant longtemps, le deuxième critère a prédominé, sans doute afin de minimiser le nombre de caractères à saisir pour un utilisateur. Les règles issues de cette approche imposent ainsi d’utiliser plusieurs classes de caractères (minuscules, majuscules, chiffres, ponctuations), pour une taille minimale située autour d’une dizaine de caractères. L’ANSSI recommandait ainsi en 2012 une taille minimale de 12 caractères, pour 3 classes de caractères, qu’il faudrait sans doute réactualiser pour tenir compte de l’évolution des moyens de calculs disponibles.

Néanmoins, cette approche ne fait plus consensus aujourd’hui. Le NIST, dans sa dernière recommandation de 2017 recommandait ainsi de permettre l’utilisation de mots de passes longs, sans l’imposer, mais sans règle de composition associée:

Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization.

Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets.

Ce changement n’est pas dû à une soudaine infiltration par des hippies, mais à une simple constatation pragmatique qui se répète régulièrement lors des fuites massives de comptes utilisateurs compromis : les humains ayant une capacité limitée à mémoriser des secrets complexes, ils ont tendance à choisir des mots de passes simples à deviner. Ce qui est parfaitement résumé en image par XKCD.

Les deux approches coexistent aujourd’hui, et il est difficile objectivement d’affirmer laquelle des deux approches est la meilleure en termes de sécurité. Le contexte d’utilisation est donc sans doute un critère de choix plus objectif, étant donné par exemple que les terminaux mobiles se prêtent mal à la saisie de mots de passe long. Et accessoirement, il faut garder à l’esprit que de toute façon, la robustesse d’un mot de passe ne protège que des attaques par force brute, et absolument pas contre d’autres types d’attaques, comme par exemple l’interception du mot de passe sur le réseau, l’extorsion du mot de passe par ruse (phishing), voire par d’autres moyens moins subtils, comme illustré encore une fois par XKCD. ​

 

 

RENOUVELLEMENT RÉGULIER

Le renouvellement réguliers des mots de passe a longtemps été considéré comme strictement nécessaire à toute PSSI qui se respecte. Le guide de l’ANSSI déjà cité préconise ainsi de les renouveler tous les 90 jours, pour les systèmes contenant des données sensibles.

Là aussi, le consensus évolue, et le NIST, qui a peut-être bien été infiltré finalement, innove en proposant d’abandonner cette pratique, et de ne procéder à un renouvellement qu’en cas de compromission avérée:

Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise.

Encore une fois, il est difficile de se faire un avis objectif sur le gain en sécurité. Mais au vu des difficultés techniques à mettre en place cette mesure dans un système d’information hétérogène, sans maitrise du poste de travail, et des difficultés organisationnelles à la faire accepter des utilisateurs, qui rivalisent souvent d’ingéniosité pour la contourner, il est facile de constater que le rapport cout/bénéfice est relativement bas.

 

 

NON-RÉUTILISATION

Alors que les certitudes s’écroulent, il est réconfortant de constater qu’il reste des conseils faisant consensus, et notamment celui d’éviter de réutiliser le même mot de passe dans des contextes différents. La notion de contexte correspond ici à celle de frontière de confiance: il ne parait pas pertinent d’interdire la réutilisation entre deux applications professionnelles, alors que tout l’enjeu de l’authentification centralisée consiste justement à utiliser le même compte utilisateur partout, mais bien entre applications mises en œuvre par des tiers différents. Pour simplifier, il est généralement plus simple de faire passer cette frontière entre la sphère professionnelle et la sphère personnelle, comme le fait par exemple le guide de l’ANSSI:

En particulier, l’utilisation d’un même mot de passe pour sa messagerie professionnelle et pour sa messagerie personnelle est à proscrire impérativement.

Malheureusement, il s’agit essentiellement d’une préconisation, très difficile à vérifier opérationnellement. Il est certes possible de vérifier la présence d’un mot de passe dans un dictionnaire de mots de passes communément utilisés ou connus comme compromis, au moment de sa création ou son renouvellement. Voire même de mener régulièrement des attaques par dictionnaire sur sa propre base de comptes, mais ceci nécessite généralement une organisation technique spécifique, et un encadrement organisationnel. La meilleure stratégie consiste donc à faciliter l’application de cette préconisation par les utilisateurs, typiquement par l’utilisation d’applications dédiés au stockage des mots de passe, intégrés aux applications les plus courantes (le navigateur web, essentiellement). On peut citer ici KeePass et ses dérivés, comme par exemple KeePassXC, plus simple à mettre en œuvre sur Linux. ​

 

 

LIMITATION D’USAGE

Enfin, le moyen le plus radical de limiter le risque consiste à le supprimer, quand c’est possible. Dans le cas des mots de passe, il existe parfois des alternatives simples à mettre en place, en fonction du contexte et des utilisateurs concernés.

Le cas typique, c’est celui des connexions SSH sur des serveurs Unix, ou des serveurs Windows depuis la version 2019. En effet, il est trivial d’utiliser une authentification par clé, plutôt que par mot de passe, en passant par mécanisme externe (annuaire LDAP, gestion de configuration, déploiement manuel par un tiers, …) pour mettre en place les clés publiques correspondantes. De surcroit, en utilisant un agent SSH (ssh-agent sous Unix, pageant avec Putty, …) les utilisateurs y gagneront un mécanisme de type SSO, c’est-à-dire qu’ils vont bénéficier d’un gain d’ergonomie, ce qui est rarement le cas lors d’une augmentation de la sécurité. Enfin, en bloquant l’authentification par mot de passe (PasswordAuthentication no dans la configuration de sshd), le risque d’une authentification par force brute disparait, et avec lui le besoin de déployer des solutions plus ou moins complexes d’inspection des logs et de modification dynamique du contrôle d’accès réseau.

 

 

CONCLUSIONS

L’évolution des technologies, d’une part, des usages, d’autre part, entraine une évolution conjointe des méthodes d’attaques. Les changements dans le discours des experts en sécurité ne fait que refléter une volonté de s’adapter à ces évolutions, à la lumière notamment de l’expérience des accidents de sécurité récurrents, tout en gardant le même objectif final: réduire le risque à un niveau acceptable. Et pour ceux qui s’inquiètent de voire le NIST se transformer en refuge de bisounounours, qu’ils se rassurent: l’allégement des préconisations affectant les utilisateurs correspond en fait à un transfert des contraintes vers les fournisseurs de service, plus à même de mettre en place des mesures plus complexes, mais considérées comme plus efficaces à l’heure actuelles. Comme par exemple la vérification du mot de passe choisi par un utilisateurs dans des listes noires constituées à partir des bases de données de comptes compromis qui fuitent régulièrement sur internet.

 

 

Auteur : Guillaume Rousse ; Ingénieur Sécurité à RENATER. Article GEANT : https://connect.geant.org/2020/10/29/some-tips-to-secure-your-passwords

X