Aider l'utilisateur à créer un bon mot de passe

L'objectif dans la création d'un mot de passe est double : obtenir un secret difficile à deviner, sans épuiser la personne qui le choisit.

Une majuscule, un chiffre, un symbole, un changement tous les trois mois. Ces règles, qui sont souvent en places lorsqu'il faut créer un mot de passe partent d'une bonne intention, mais l'analyse des fuites a montré qu'elles protègent peu et fatiguent beaucoup. NIST1, OWASP2 et le NCSC3 convergent aujourd'hui vers l'approche inverse : moins de contraintes sur l'utilisateur, plus de défenses côté système.

Ce qui a changé, et pourquoi

Deux règles ont longtemps structuré les politiques de mot de passe : les règles de composition, qui imposent un mélange de types de caractères, et la rotation périodique, qui force un changement tous les trente, soixante ou quatre-vingt-dix jours. Elles se sont répandues partout. NIST et le NCSC les écartent désormais, et expliquent pourquoi.

La complexité imposée échoue parce que les utilisateurs y répondent de façon prévisible4. Quelqu'un qui aurait choisi "password" choisira "Password1" si on exige une majuscule et un chiffre, puis "Password1!" si on exige un symbole. L'analyse des bases de mots de passe ayant fuité montre que le gain de sécurité est faible.

La rotation périodique échoue pour des raisons concrètes, listées par le NCSC3. La rotation fabrique surtout des mots de passe légèrement modifiés, faciles à deviner.

• l'utilisateur choisit une variante mineure de l'ancien mot de passe
• un mot de passe volé est exploité tout de suite sans attendre l'échéance
• forcer un changement n'apprend rien sur une éventuelle compromission
• un attaquant déjà dans le compte reçoit aussi la demande de réinitialisation

Le principe qui remplace ces règles tient en une phrase : privilégier la longueur à la complexité, et confier la protection à des défenses techniques plutôt qu'au comportement de l'utilisateur. Limitation des tentatives, MFA, listes de blocage et stockage haché font le travail que la complexité prétendait faire4.

La politique de mot de passe

Voici les règles à appliquer au moment de la création, telles que NIST les formule1 et qu'OWASP les reprend2.

• SHALL 15 caractères minimum en facteur unique. En MFA, on peut descendre, mais jamais sous 8.
• SHALL Il ne tronque jamais la saisie de lui-même.
• SHOULD Le système accepte au moins soixante-quatre caractères, pour autoriser les phrases de passe.
• MAY Combiné à un second facteur, il peut descendre plus bas

Pas de complexité imposée :

• SHALL NOT Pas de rotation forcée. Le changement périodique n'est plus imposé, et un renouvellement n'est demandé qu'en cas de soupçon de compromission.
• SHALL NOT le système n'exige aucune règle de composition, ni majuscule, ni chiffre, ni symbole,
• SHALL à la place, une liste de blocage refuse les mots de passe trop courants ou déjà compromis, et le motif du refus est affiché clairement.
• SHALL NIST demande aussi d'accompagner ce refus d'un conseil pour choisir un meilleur mot de passe, afin d'éviter que l'utilisateur ne se contente d'une variante du mot rejeté.
• SHOULD Le système accepte tous les caractères imprimables, espaces et caractères Unicode compris (chaque caractère Unicode comptant pour un seul)

Le coût caché

La complexité ne se paie pas au moment de la création, mais à la connexion suivante. Un utilisateur arrive presque toujours à fabriquer un mot de passe conforme sur le moment. Mais plus on ajoute de contraintes, moins il parvient à le retrouver ensuite. L'indicateur qui compte n'est donc pas le taux de création de compte réussie, mais le taux d'échec à la reconnexion.

L'échec de reconnexion enclenche une réaction en chaîne coûteuse : plusieurs tentatives, puis une réinitialisation, qui dépend d'un e-mail. Ces règles poussent l'utilisateur hors de sa stratégie habituelle (sa "formule" personnelle), ce qui l'amène à réutiliser un mot de passe, à l'écrire dans un endroit peu sûr, ou à recourir à des substitutions prévisibles comme « 0 » pour « o ». La complexité imposée, censée renforcer la sécurité, dégrade donc à la fois l'expérience et la sécurité réelle.

• Annoncer les règles d'emblée : Si des contraintes subsistent, elles doivent être visibles avant que l'utilisateur commence à taper, à proximité immédiate du champ.
• Validation en direct : Pour les cas où plusieurs règles coexistent, une validation inline qui se confirme au fur et à mesure (chaque critère passant au vert quand il est rempli) supprime l'essentiel de l'essai-erreur
• Dire quoi corriger : En cas de refus, indiquer le critère précis manquant, jamais un vague "mot de passe invalide".

Aider l'utilisateur à saisir

• SHOULD Un bouton qui révèle le texte saisi évite les fautes de frappe répétées.
• SHOULD Autoriser le collage, et ne jamais le bloquer par du JavaScript (c'est ce qui permet aux gestionnaires de remplir le champ)8

Préférer une jauge de force fondée sur une vraie estimation plutôt qu'une liste de cases à cocher. Une bibliothèque comme zxcvbn évalue la résistance réelle d'un mot de passe2. Ces jauges restent imparfaites, elles repèrent mal les informations personnelles ou les répétitions, ce qu'il faut garder en tête3.

Le NCSC recommande les "trois mots au hasard", qui produisent une phrase de passe longue et facile à retenir7. Par exemple "vélo orange tonnerre" est plus long, et souvent plus solide, que "V3lo!" : chaque caractère ajouté élargit l'espace de recherche bien plus vite que le remplacement d'une lettre par un symbole, et une variante évidente comme "Password1!" se retrouve de toute façon sur les listes de blocage.

Quand un mot de passe est refusé, dire pourquoi, sur le champ et précisément : trop court, déjà compromis, identique au nom du service. Un refus sans explication pousse l'utilisateur à abandonner. À l'inverse, NIST autorise de petites tolérances bienveillantes à la saisie, comme retirer les espaces en début et en fin avant de vérifier, tant que la longueur minimale reste respectée. MAY

<!-- Champ de création : aide les gestionnaires et l'autofill -->
<label for="new-password">Mot de passe</label>
<input
  id="new-password"
  type="password"
  autocomplete="new-password"
  minlength="15"
  aria-describedby="pw-hint">
<button type="button" aria-pressed="false">Afficher</button>
<p id="pw-hint">Trois mots au hasard font une bonne phrase de passe. Le collage est accepté.</p>

Compatibilité avec les gestionnaires de mots de passe

Les gestionnaires sont aujourd'hui le meilleur allié d'un mot de passe robuste. Ils génèrent des secrets longs, uniques et aléatoires, et suppriment la tentation de réutiliser le même partout. Le NCSC recommande de les autoriser sur tous les services, et d'autoriser le collage dans les formulaires3.

La combinaison la plus solide, selon le NCSC, associe un mot de passe généré par la machine et un gestionnaire qui le conserve3. Sans gestionnaire, un mot de passe aléatoire devient impossible à retenir et multiplie les demandes de réinitialisation. C'est donc le couple générateur plus gestionnaire qu'il faut encourager, pas le mot de passe aléatoire seul.

Mettre tout ça en place dans une grande structure

Cependant, en pratique appliquer ces recommandations dans une grande organisation se heurte à des obstacles techniques et politiques.

Côté obstacles, plusieurs reviennent souvent :

• Des systèmes anciens codent en dur la rotation et les règles de composition et ne savent pas faire autrement
• Des référentiels de conformité ou d'audit, parfois interprétés de façon datée, continuent d'exiger le changement périodique
• Et une habitude installée, "on a toujours fait comme ça", rend tout changement suspect : assouplir une règle de sécurité peut donner l'impression de baisser la garde

Plusieurs leviers aident à conduire le changement. L'idée est de montrer que l'on déplace l'effort, on ne baisse pas la garde.

• Cadrer la réforme comme un transfert de charge, pas un relâchement. Les défenses techniques (limitation des tentatives, MFA, listes de blocage, surveillance des connexions) reprennent le travail que la complexité prétendait faire, et le font mieux. C'est l'argument à porter en priorité auprès des équipes sécurité et conformité.
• Procéder par groupes pilotes et mesurer. Déployer sur un service d'abord, puis suivre un indicateur concret : le nombre de réinitialisations de mot de passe au support. Sa baisse est l'argument le plus parlant pour généraliser.
• Adapter la politique à la criticité du compte. Un compte standard se contente d'une longueur minimale et de la MFA. Un compte à privilèges (administrateur) justifie une clé de sécurité physique et un compte dédié, distinct du compte courant et jamais utilisé pour lire ses e-mails ou naviguer.
• Former en expliquant le pourquoi. Une liste d'interdits ne change pas les habitudes ; comprendre que « trois mots au hasard » bat « P@ssw0rd! » les change. Privilégier la pédagogie au règlement.
• Traiter le legacy de front. Recenser les systèmes qui codent en dur la rotation, et confronter les référentiels d'audit datés à la version actuelle des recommandations NIST/NCSC plutôt que de subir leur interprétation par défaut.