Arrêter de faire changer les mots de passe tous les trois mois

C’est probablement la mesure de sécurité la plus répandue au monde, et l’une des rares que les deux principales agences de cybersécurité anglo-saxonnes recommandent explicitement de supprimer. Le NCSC britannique écrit, en titre de section : « n’imposez pas d’expiration régulière des mots de passe ». Le NIST l’écrit en exigence normative : les vérificateurs « NE DOIVENT PAS exiger des abonnés qu’ils changent périodiquement de mot de passe ». Et pourtant la case est cochée dans à peu près toutes les politiques de sécurité, parce que personne n’a envie d’être celui qui l’a décochée.

→ Lire l’explication complète de la marmotte

Cinq raisons pour lesquelles l’expiration ne marche pas

Le NCSC commence par le constat : « le changement régulier de mot de passe nuit à la sécurité plutôt qu’il ne l’améliore. De nombreux systèmes forcent les utilisateurs à changer leur mot de passe à intervalles réguliers, typiquement tous les 30, 60 ou 90 jours. Cela impose une charge à l’utilisateur, et il y a des coûts associés à la récupération des comptes. » Puis il énumère cinq raisons pour lesquelles l’expiration forcée « n’apporte aucun bénéfice réel », et chacune mérite d’être prise au sérieux.

L’utilisateur choisira une variation mineure de l’ancien mot de passe. C’est le comportement observé partout : un incrément, un mois, un point d’exclamation. Un attaquant qui détient l’ancien le devine en quelques essais, d’autant plus facilement que les règles de complexité imposent des transformations prévisibles.

Les mots de passe volés sont généralement exploités immédiatement. Le délai moyen entre le vol et l’usage est de l’ordre de l’heure ou du jour, pas du trimestre. Une rotation trimestrielle protège contre un attaquant qui aurait attendu plus de quatre-vingt-dix jours sans rien faire, cas de figure rare. L’économie réelle de la revente d’accès est décrite dans les courtiers d’accès initial, et l’incident DGFiP en fournit l’illustration chiffrée : l’attaquant se connectait dans les jours suivant le vol.

La réinitialisation ne vous apprend rien sur la survenue d’une compromission. C’est l’argument le plus fort, et le moins entendu. Une mesure de sécurité qui ne produit aucune information est une mesure dont on ne peut pas évaluer l’effet. On change, on ne sait pas si c’était utile, on recommence dans trois mois.

Un attaquant qui a accès au compte recevra probablement aussi la demande de réinitialisation. Et pourra donc choisir lui-même le nouveau mot de passe. L’expiration, dans ce cas, aide l’attaquant à consolider son accès en évinçant l’utilisateur légitime.

Si la compromission vient d’un stockage non sûr, l’attaquant trouvera le nouveau mot de passe au même endroit. Le pense-bête sous le clavier, le fichier de notes, le gestionnaire mal protégé : la rotation y écrit la nouvelle valeur.

Une exception, et le NCSC la met en note explicite : « les utilisateurs doivent changer leur mot de passe quand vous savez, ou soupçonnez, qu’il a été compromis ». Le NIST dit la même chose dans la même exigence : pas de changement périodique, mais « les vérificateurs DOIVENT forcer un changement s’il existe une preuve que l’authentificateur a été compromis ». La rotation n’est pas abolie, elle devient déclenchée par un événement plutôt que par un calendrier.

Ce que le NIST exige à la place

La liste des exigences du NIST sur les mots de passe est courte, normative, et bien plus exigeante que la plupart des politiques en vigueur, mais pas sur les mêmes points.

Sur la longueur, d’abord, et les chiffres surprennent : les vérificateurs « DOIVENT exiger que les mots de passe utilisés comme mécanisme d’authentification à facteur unique aient une longueur minimale de 15 caractères », et « PEUVENT autoriser des mots de passe plus courts lorsqu’ils ne servent que dans un processus multifacteur, mais DOIVENT exiger un minimum de huit caractères ». Quinze caractères pour un mot de passe seul, c’est très au-delà des huit habituels ; et huit suffisent dès qu’un second facteur existe. Le troc est explicite, et il récompense le déploiement du multifacteur. La longueur maximale « DEVRAIT être d’au moins 64 caractères », tous les caractères ASCII imprimables et l’espace « DEVRAIENT » être acceptés, Unicode également, chaque point de code comptant pour un caractère.

Sur les règles de composition, l’interdiction est sans ambiguïté : les vérificateurs « NE DOIVENT PAS imposer d’autres règles de composition », par exemple l’exigence de mélanger des types de caractères. Le NCSC développe le raisonnement : ces règles sont « une mauvaise défense contre les attaques par devinette », elles imposent une charge supplémentaire aux utilisateurs « dont beaucoup utiliseront des motifs prévisibles, comme remplacer la lettre o par un zéro, pour satisfaire aux critères de complexité requis », et « les attaquants connaissent ces stratégies et utilisent cette connaissance pour optimiser leurs attaques ». Il ajoute l’argument de périmètre : les règles de complexité « ne fournissent aucune défense contre des types d’attaques courants comme l’ingénierie sociale ou le stockage non sûr ». Le site dispose par ailleurs d’une page sur l’outil qui exploite les empreintes volées hors ligne, Hashcat, et l’effet des règles de composition sur son efficacité est exactement celui que le NCSC décrit.

Trois interdictions complètent la liste. Pas d’indice de rappel stocké et accessible à un non-authentifié. Pas de questions personnelles : les vérificateurs « NE DOIVENT PAS inviter les abonnés à utiliser une authentification fondée sur la connaissance, par exemple quel était le nom de votre premier animal, ni des questions de sécurité lors du choix d’un mot de passe ». Et pas de troncature : le vérificateur « DOIT demander le mot de passe en entier, et non un sous-ensemble, et DOIT vérifier le mot de passe soumis dans son intégralité ».

Reste l’exigence qui remplace réellement l’expiration : la liste d’interdiction. Lors de l’établissement ou du changement d’un mot de passe, le vérificateur « DOIT comparer le secret envisagé à une liste de blocage contenant des mots de passe connus comme communément utilisés, attendus ou compromis », la comparaison portant sur « le mot de passe entier, et non sur des sous-chaînes ». Le NIST précise le contenu : mots de passe issus de fuites antérieures, mots du dictionnaire, et « mots spécifiques au contexte, tels que le nom du service, le nom d’utilisateur, et leurs dérivés ». En cas de rejet, il faut en donner la raison et offrir des conseils, « ce qui est particulièrement important après le rejet d’un mot de passe figurant sur la liste, car cela décourage les modifications triviales ». Et une note utile à qui voudrait acheter la plus grosse base possible : « des listes de blocage excessivement grandes n’apportent qu’un bénéfice de sécurité marginal, parce que la liste sert à défendre contre des attaques en ligne, lesquelles sont déjà limitées par les exigences de limitation de débit ».

Ce qui remplace l’expiration, côté exploitation

Le NCSC propose une liste de contre-mesures à mettre à la place, et c’est elle qu’il faut présenter quand on propose de retirer l’expiration : il ne s’agit pas de supprimer un contrôle, mais de le remplacer par quatre qui fonctionnent.

Limiter les tentatives, d’abord, et son conseil est précis sur le choix de la méthode. La temporisation progressive entre tentatives successives « est préférable, parce que le verrouillage de compte peut laisser des utilisateurs légitimes dans l’incapacité d’accéder à leur compte, et requiert un moyen de récupération ». Le verrouillage « peut offrir à un attaquant un moyen facile de lancer un déni de service, en particulier pour de grands systèmes en ligne ». Si l’on verrouille malgré tout, il recommande « entre 5 et 10 tentatives avant le gel du compte, pour éviter les verrouillages accidentels ». Les techniques par lesquelles un attaquant contourne ces limitations sont décrites dans le contournement d’un rate limit.

Superviser, ensuite, avec quatre signaux que le NCSC nomme : les tentatives de connexion qui échouent à la seconde étape du multifacteur, la force brute et la pulvérisation de mots de passe, les connexions depuis des zones géographiques inattendues, et les signalements d’utilisateurs sur des verrouillages ou des comportements inhabituels. Le troisième relève de la détection de l’impossible travel ; le premier est le plus sous-exploité, parce qu’un échec au second facteur signifie qu’un attaquant détient déjà le premier.

Tenir les processus d’arrivée et de départ, et verrouiller automatiquement les comptes inactifs : deux mesures organisationnelles qui font ce que l’expiration prétendait faire, à savoir fermer les accès qui n’ont plus de titulaire. C’est l’objet de l’audit des comptes orphelins et de sa mise en œuvre sur un annuaire. Encourager le signalement, enfin, avec une remarque fine du NCSC : certaines formes de multifacteur, code par message ou notification, « peuvent même avertir l’utilisateur qu’il a été compromis, puisqu’il recevra un code qu’il n’a pas demandé », à condition que la formation lui ait appris à le signaler ; c’est le genre de message que traitent les micro-formations de sensibilisation.

Et par-dessus tout, le multifacteur, qui « rendra un mot de passe compromis moins utile à un attaquant ». Le NCSC recommande de le réserver en priorité aux situations à risque supplémentaire, nouvel appareil, systèmes exposés sur Internet, comptes prioritaires, et de prioriser les comptes privilégiés et externes, avec une remarque qui conclut le débat sur la complexité : « imposer des exigences de complexité supplémentaires à ces comptes augmentera la charge de ces utilisateurs, mais peut ne fournir aucune protection de plus ». Le choix du facteur, lui, n’est pas indifférent : voir les niveaux d’assurance d’authentification et le déploiement de FIDO2 pour les comptes à privilèges.

Le stockage, le gestionnaire, et le partage

Trois points pratiques, parce qu’une politique sans eux reste incomplète.

Le stockage doit résister à une attaque hors ligne. Le NIST exige que les mots de passe soient « salés et hachés avec un schéma de hachage de mot de passe adapté », dont « le but est de rendre chaque devinette plus coûteuse pour un attaquant ayant obtenu un fichier d’empreintes ». Le facteur de coût « DEVRAIT être aussi élevé que possible sans dégrader les performances du vérificateur » et « DEVRAIT être augmenté au fil du temps pour tenir compte de l’augmentation de la puissance de calcul ». Le sel « DOIT avoir une longueur d’au moins 32 bits », le sel et l’empreinte doivent être stockés pour chaque mot de passe, et une référence au schéma utilisé, facteur de coût inclus, « DEVRAIT être stockée pour chaque mot de passe afin de permettre la migration vers de nouveaux algorithmes ». Cette dernière exigence est la plus souvent oubliée, et c’est celle qui décide de la possibilité de migrer sans réinitialiser tout le parc ; le mécanisme est détaillé dans transformer mots de passe et secrets applicatifs en clés.

Le gestionnaire de mots de passe n’est plus toléré, il est exigé : les vérificateurs « DOIVENT autoriser l’usage des gestionnaires de mots de passe et de la fonction de remplissage automatique », et « DEVRAIENT permettre la fonction coller », le NIST notant que « les gestionnaires se sont révélés augmenter la probabilité que les abonnés choisissent des mots de passe plus forts, en particulier s’ils incluent des générateurs ». Le NCSC va dans le même sens et recommande que « tous les services en ligne permettent l’usage de gestionnaires de mots de passe, et que les utilisateurs soient autorisés à coller les mots de passe dans les formulaires web ». Tout site qui bloque le collage dégrade activement la sécurité de ses utilisateurs. Le NIST ajoute une recommandation d’ergonomie qui n’a l’air de rien : offrir « une option pour afficher le mot de passe, plutôt qu’une série de points ou d’astérisques, pendant sa saisie », afin que l’utilisateur puisse vérifier son entrée quand son écran n’est pas observable.

Le partage, enfin, que le NCSC traite sans détour : partager un compte « annule le bénéfice d’authentifier un utilisateur spécifique », et surtout « la capacité d’auditer et de superviser les actions d’un utilisateur spécifique est perdue, exigence forensique essentielle pour certains comptes ». Sa recommandation est de préférer la délégation de privilèges au partage de mot de passe, et, s’il n’y a pas d’autre solution, de limiter le partage « au plus petit groupe possible d’utilisateurs connus et de confiance » et de changer le mot de passe dès qu’une personne n’y a plus droit. Le site traite ce sujet dans la suppression des comptes de service partagés et, du point de vue humain, dans le mot de passe partagé en équipe.

Conduire le changement, parce que c’est là que ça bloque

La partie technique de cette page est facile : il s’agit de décocher une case et d’en cocher quatre autres. La difficulté est ailleurs, et il vaut mieux l’anticiper.

Le premier obstacle est l’audit. Beaucoup de référentiels d’audit, de questionnaires d’assurance et de grilles de conformité internes contiennent encore une ligne sur la rotation périodique, et un auditeur qui coche des cases produira une non-conformité. La réponse n’est pas de discuter mais de documenter : une politique écrite qui cite les deux référentiels, explique les cinq raisons et liste les contrôles de remplacement transforme une non-conformité en point de divergence argumenté. Et il faut que les contrôles de remplacement soient réellement en place, car l’absence d’expiration sans liste d’interdiction, limitation des tentatives, détection et multifacteur est une dégradation nette, non une modernisation.

Le second obstacle est culturel. L’expiration trimestrielle est visible, donc rassurante ; les contrôles qui la remplacent sont invisibles. Il faut donc expliquer, et le NCSC consacre son sixième conseil à ce point en relevant que la formation habituelle, faite de listes de choses à faire et à ne pas faire, « peut être contre-productive, car vos conseils peuvent contredire ce qu’ils ont entendu ailleurs ». Un utilisateur à qui l’on a répété pendant quinze ans qu’un bon mot de passe est court, compliqué et renouvelé souvent n’adoptera pas sans explication l’idée qu’il est long, simple et permanent.

Le troisième obstacle est le plus insidieux : retirer l’expiration ne dispense pas de regarder ce qu’il y a dans la base. Si les mots de passe actuels ont été choisis sous un régime de complexité et de rotation, leur rendre la permanence ne les améliore pas. Le NCSC suggère, lorsqu’on ne peut pas filtrer à la création, de « rechercher rétroactivement dans sa base les empreintes des mots de passe interdits ». La bonne séquence est donc : mettre en place la liste d’interdiction et la limitation des tentatives, forcer un dernier changement pour les comptes concernés, puis retirer l’expiration. Dans cet ordre. Le meilleur aboutissement reste de ne plus avoir de mot de passe du tout, voie décrite dans le déploiement du passwordless dans un parc hétérogène.

Sources

Password policy: updating your approach, National Cyber Security Centre, Royaume-Uni.
NIST SP 800-63B-4 : Digital Identity Guidelines, Authentication and Authenticator Management, NIST, juillet 2025.

🐝 Ce qui arrive si on s’en passe

En conservant l’expiration périodique, on obtient des mots de passe qui ne diffèrent du précédent que par un chiffre, un volume de réinitialisations à traiter, et aucune information sur l’existence d’une compromission ; un attaquant déjà installé reçoit la demande de renouvellement et choisit le nouveau mot de passe. En conservant les règles de composition, on pousse les utilisateurs vers des transformations prévisibles que les outils de cassage connaissent et exploitent. En retirant l’expiration sans mettre en place de liste d’interdiction, on laisse en place les mots de passe les plus devinés du monde, sans la rotation qui les renouvelait par accident. Sans limitation des tentatives, aucune liste d’interdiction n’empêche la force brute. Sans supervision des échecs au second facteur, on ignore les cas où un attaquant détient déjà le premier. Sans référence au schéma de hachage stockée avec chaque empreinte, toute migration d’algorithme oblige à réinitialiser l’ensemble du parc. Et en interdisant le collage dans les formulaires, on empêche l’usage des gestionnaires, donc des mots de passe réellement aléatoires.

🦫 Explication de la marmotte 🍫

Faire changer le mot de passe tous les trois mois est une habitude universelle, et les deux grandes agences de cybersécurité britannique et américaine recommandent de l’arrêter. Leurs raisons sont concrètes. L’utilisateur ne change pas vraiment de mot de passe, il ajoute un chiffre. Un mot de passe volé est utilisé dans les heures qui suivent, pas trois mois plus tard. Le changement ne vous apprend rien : vous ne savez pas davantage si quelqu’un était entré. Si quelqu’un est déjà entré, il reçoit la demande de changement et choisit le nouveau. Et si le mot de passe était noté quelque part, le nouveau le sera au même endroit.

Même raisonnement pour les règles de complexité, qui exigent une majuscule, un chiffre et un caractère spécial : les utilisateurs appliquent tous les mêmes recettes, remplacer un o par un zéro par exemple, et les outils d’attaque connaissent ces recettes.

Ce qui remplace ces deux mesures tient en quatre contrôles. Refuser à la création les mots de passe figurant sur une liste des plus courants et des plus souvent volés, y compris ceux qui contiennent le nom du service. Ralentir progressivement les tentatives de connexion échouées, plutôt que de bloquer le compte, ce qui éviterait de donner à un attaquant le moyen de paralyser tout le monde. Surveiller quelques signaux simples, en particulier les échecs à la seconde étape d’une authentification à deux facteurs, qui signalent que quelqu’un possède déjà le mot de passe. Et déployer ce second facteur, qui rend le mot de passe volé beaucoup moins utile.

Deux détails pratiques comptent autant. Un mot de passe seul doit être long, quinze caractères selon les recommandations américaines ; il peut être plus court dès qu’un second facteur existe. Et il faut autoriser les gestionnaires de mots de passe, donc permettre le collage dans les formulaires : un site qui l’interdit empêche ses utilisateurs d’avoir des mots de passe réellement solides.

Dernière précision, pour éviter un contresens : on change toujours un mot de passe quand on sait ou soupçonne qu’il a été compromis. Ce qui disparaît, c’est le changement au calendrier, pas le changement sur événement.

Pages voisines

La citent

Authentifier les personnes et les services

Arrêter de faire changer les mots de passe tous les trois mois

Elle cite

Arrêter de faire changer les mots de passe tous les trois mois

Arrêter de faire changer les mots de passe tous les trois mois

Cinq raisons pour lesquelles l’expiration ne marche pas

Ce que le NIST exige à la place

Ce qui remplace l’expiration, côté exploitation

Le stockage, le gestionnaire, et le partage

Conduire le changement, parce que c’est là que ça bloque

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines