De nombreuses règles courantes sur les mots de passe compliquent la vie des utilisateurs sans empêcher les attaques modernes. Découvrez les mesures recommandées aujourd’hui par le NIST, le NCSC et Microsoft.
La politique de mots de passe est souvent réduite à une liste d’exigences : une majuscule, un chiffre, un symbole et un changement tous les 60 ou 90 jours. Ces règles sont visibles et faciles à contrôler, mais leur visibilité ne garantit pas leur efficacité. Les attaquants exploitent les choix humains prévisibles, les identifiants réutilisés, les procédures de récupération peu sûres et les bases de données de mots de passe mal protégées.
Une politique utile doit réduire ces risques concrets tout en restant suffisamment facile à respecter pour que les utilisateurs ne cherchent pas à la contourner.
Longueur minimale
La longueur élargit l’espace de recherche, mais uniquement si le mot de passe n’est pas une expression courante ou une suite prévisible. Les recommandations actuelles du NIST exigent au moins 15 caractères lorsque le mot de passe est le seul facteur d’authentification et autorisent un minimum plus faible, de huit caractères, lorsqu’il est utilisé dans le cadre d’une authentification multifacteur. Les systèmes doivent accepter au moins 64 caractères pour permettre le bon fonctionnement des gestionnaires de mots de passe et l’utilisation de phrases de passe.
La longueur est une exigence de base, pas une preuve de robustesse. Une liste de blocage des mots de passe compromis est nécessaire, car un mot de passe long déjà connu des attaquants reste dangereux.
Expiration périodique des mots de passe
Les changements imposés à intervalles fixes tendent à entraîner des modifications mineures et prévisibles. Ils font aussi peser une contrainte sur chaque utilisateur, sans preuve que chaque mot de passe ait été exposé. Le NIST, le NCSC du Royaume-Uni et Microsoft déconseillent l’expiration périodique. Il faut plutôt changer un mot de passe lorsque des éléments indiquent une compromission ou qu’il existe un soupçon raisonnable de compromission, après la découverte d’un mode de stockage vulnérable, ou lorsqu’une procédure de récupération de compte l’exige.
Les organisations doivent néanmoins pouvoir détecter rapidement les incidents et réinitialiser les mots de passe. Supprimer le renouvellement périodique ne signifie pas conserver un mot de passe dont la compromission est avérée.
Règles de composition
Les règles imposant des majuscules, des minuscules, des chiffres et des symboles favorisent des schémas tels qu’une majuscule en première position et un chiffre ou un symbole à la fin. Les outils d’attaque tiennent déjà compte de ces substitutions. Les services doivent autoriser les espaces et une large gamme de caractères, éviter les règles de composition arbitraires et comparer l’intégralité du mot de passe proposé aux mots de passe courants et compromis.
Interdire les signes de ponctuation au motif qu’ils pourraient servir à une injection SQL ou à une attaque de type cross-site scripting est un signal d’alerte. Le code de l’application doit utiliser des requêtes paramétrées pour interroger la base de données et traiter les données de sortie de manière sécurisée. Restreindre les mots de passe des utilisateurs ne remplace pas la correction des vulnérabilités d’injection.
Réutilisation des mots de passe et identifiants compromis
La réutilisation est l’un des risques les plus lourds de conséquences, car une fuite chez un fournisseur peut ouvrir l’accès à des comptes chez un autre. Une politique doit exiger un mot de passe propre au service, prendre en charge les gestionnaires de mots de passe et vérifier les mots de passe proposés par rapport aux mots de passe dont la compromission est connue, à l’aide d’une méthode qui protège la vie privée. Les organisations doivent également surveiller les schémas de bourrage d’identifiants et les comportements de connexion inhabituels.
L’historique des mots de passe peut empêcher la réutilisation à l’identique au sein d’un même service, mais un historique très long peut inciter à des modifications superficielles. Il ne permet pas de détecter la réutilisation chez d’autres fournisseurs et ne doit pas être considéré comme la principale mesure de protection.
Stockage sécurisé des mots de passe
Les mots de passe ne doivent être transmis au service que par une connexion TLS protégée et ne doivent jamais être consignés dans les journaux. Côté serveur, chaque mot de passe doit être traité avec un sel aléatoire unique et une fonction de hachage lente conçue pour les mots de passe. OWASP recommande généralement Argon2id ; scrypt, bcrypt ou PBKDF2 peuvent convenir sous certaines contraintes explicites. Les paramètres de coût doivent être réévalués périodiquement à mesure que le matériel gagne en puissance.
Un secret de type « pepper », stocké en dehors de la base de données des mots de passe, peut ajouter une couche de protection, mais il impose des responsabilités en matière de gestion et de renouvellement des clés. Il ne remplace ni un sel ni une fonction robuste de hachage des mots de passe. Les fonctions de hachage rapides à usage général, telles que MD5 et SHA-1/SHA-2 utilisés seuls, ne conviennent pas, à elles seules, au stockage des mots de passe.
Ce que comprend une politique efficace
Une longueur minimale adaptée au risque et la prise en charge des mots de passe longs.
Le blocage des mots de passe courants, prévisibles et dont la compromission est connue.
La prise en charge des gestionnaires de mots de passe, du collage et du remplissage automatique.
Un hachage lent des mots de passe, avec un sel unique et des paramètres de coût réévalués.
Une limitation du débit et une détection à plusieurs niveaux pour les tentatives de devinette, la pulvérisation de mots de passe et le bourrage d’identifiants.
Une MFA résistante à l’hameçonnage ou des clés d’accès, en particulier pour les comptes privilégiés et sensibles.
Des procédures sécurisées de récupération, de remplacement des authentificateurs et de révocation des sessions, ainsi que des réinitialisations déclenchées en cas de compromission.
