Notre recommandation, d’emblée. Nous éditons Proxy Mail QA, nous ne sommes donc pas neutres, mais il ne choisit pas votre politique de mots de passe. Les chiffres ci-dessous viennent des lignes directrices du NIST sur l’identité numérique (SP 800-63B, quatrième révision), suivies par de nombreuses équipes de sécurité. Nous recommandons Proxy Mail QA pour l’étape d’après : vérifier que votre formulaire et votre serveur font réellement ce que vous avez décidé, avec des mots de passe de test exactement au minimum et au maximum, un de chaque côté, et tous les types de symboles. Il n’examine ni le stockage de vos mots de passe ni votre sécurité dans son ensemble.
La réponse courte
- Au moins 15 caractères si le mot de passe suffit à lui seul pour se connecter.
- Au moins 8 caractères si chaque compte a aussi un second facteur, comme un code d’une application d’authentification.
- Autorisez au moins 64 caractères. Plus long, c’est bien ; une limite de plusieurs milliers n’est pas nécessaire.
- Pas de règles exigeant une majuscule, un chiffre et un symbole. La longueur compte davantage, et ces règles poussent les gens à choisir
Password1!. - Refusez les mots de passe courants et divulgués, en comparant les nouveaux à une liste.
Le reste des recommandations, en termes simples
Les recommandations du NIST pour les mots de passe choisis par les utilisateurs disent aussi :
- Acceptez tous les caractères : lettres, chiffres, symboles, espaces et caractères d’autres langues. Normalisez l’Unicode (en NFC) avant le hachage, pour que
ésaisi de deux façons différentes soit le même mot de passe. - Comptez les caractères, pas les octets, pour vérifier la longueur.
- Ne tronquez pas les mots de passe. Vérifiez le mot de passe entier, jamais seulement son début.
- N’imposez pas de changement de mot de passe à intervalles réguliers. Demandez un changement seulement s’il y a un signe que le mot de passe a été exposé.
- Pas d’indices de mot de passe ni de questions de sécurité.
- Autorisez le collage et les gestionnaires de mots de passe, pour que les gens puissent utiliser de longs mots de passe aléatoires sans les taper.
- Affichez ce qui a été saisi sur demande, pour que les gens puissent vérifier un long mot de passe avant de l’envoyer.
Pourquoi un maximum ?
Un mot de passe très long coûte du temps de hachage à votre serveur ; un maximum empêche donc quelqu’un d’envoyer des mégaoctets comme mot de passe. Fixez-le bien au-dessus de ce que les gens utilisent : 64 est le minimum que le NIST recommande d’autoriser, et 128 ou 256 est courant.
Surveillez votre algorithme de hachage. bcrypt ne lit que les 72 premiers octets d’un mot de passe et ignore le reste. Deux longs mots de passe qui commencent pareil permettent alors de se connecter l’un à la place de l’autre. Un caractère peut faire plus d’un octet (é en fait deux, un emoji quatre), donc 72 octets peuvent représenter moins de 72 caractères. Au choix :
- utilisez Argon2id (ou scrypt), qui n’a pas cette limite, ou
- gardez un maximum à une longueur qui tient dans 72 octets, ou
- si vous devez garder bcrypt avec des mots de passe plus longs, hachez d’abord le mot de passe d’une manière approuvée par votre équipe de sécurité.
Mettez les règles là où le navigateur peut les voir
<label for="password">Password</label><p id="password-rules">At least 15 characters. Any letters, numbers, symbols or spaces.</p><input id="password" name="password" type="password" autocomplete="new-password" minlength="15" maxlength="128" aria-describedby="password-rules" required />minlengthetmaxlengthpermettent au navigateur d’avertir tôt, et aux gestionnaires de mots de passe de créer des mots de passe conformes.maxlengthtronque aussi le texte collé sans le dire ; fixez-le donc bien au-dessus de ce que créerait un gestionnaire de mots de passe.autocomplete="new-password"indique aux gestionnaires de mots de passe de proposer un nouveau mot de passe robuste.- Affichez les règles avant la saisie, pas seulement après une erreur.
- Appliquez les mêmes règles sur le serveur. Les vérifications du navigateur sont une commodité ; n’importe qui peut les contourner.
- Si vous utilisez un service d’authentification (Supabase Auth, Clerk, Firebase Authentication, Auth0 et d’autres), réglez aussi le minimum dans ses paramètres. Beaucoup ont par défaut un minimum bien plus court, et une page qui annonce 15 alors que le service accepte 6 est un bug fréquent.
Vérifiez que votre formulaire fait ce que vous avez décidé
get_password_variants (MCP), qa.passwordVariants() (npm) ou GET /v1/variants/passwords (REST API) prennent vos règles (min_length, max_length, et si les symbols sont autorisés) et renvoient de nouveaux mots de passe de test en trois groupes :
| Groupe | Avec une politique de 15 à 64 | Ce qui doit se passer |
|---|---|---|
accept |
Exactement 15 et exactement 64 caractères ; chaque type de symbole ; une espace à l’intérieur ; éüñ |
Accepté, et permet ensuite de se connecter exactement tel que saisi |
reject |
14 caractères ; 65 caractères | Refusé, avec la règle, avant la création du compte |
decide |
Uniquement des chiffres ; uniquement des minuscules ; une espace au début ou à la fin ; un emoji ; é saisi de deux façons ; deux mots de passe partageant leurs 72 premiers octets (quand le maximum dépasse 72) |
À vous de choisir, mais délibérément. Selon le NIST, un mot de passe de 15 chiffres est autorisé sauf s’il figure dans votre liste de blocage |
La paire de 72 octets est celle à surveiller : si le second mot de passe permet de se connecter au compte créé avec le premier, votre application tronque les mots de passe.
Vous pouvez les exécuter à la main, depuis un agent ou dans un test :
- À la main : avec Proxy Mail QA for Chrome, la carte du champ de mot de passe propose Edge-case password, avec des listes marquées « Should be accepted » et « Should be rejected », adaptées aux
minlengthetmaxlengthdu champ. Ses mots de passe courants respectent aussi ces règles. - Depuis un agent : avec Proxy Mail QA connecté dans Qoder (Marketplace) :
Our password policy is 15 to 128 characters, any characters allowed. Using Proxy Mail QA,get_password_variants with min_length 15 and max_length 128, and try each one onhttps://staging.acme.dev/signup with a new test address (use a plus tag for each).For accepted ones, verify the account and sign in with the same password.Give me a table: what it tests, accepted or refused, the message shown, and whethersigning in worked.- Dans un test :
await qa.passwordVariants({ minLength: 15, maxLength: 128 })renvoieaccept,rejectetdecide, chacun une liste de{ tests, value }à parcourir dans Playwright ou Cypress.
Si les mots de passe refusés n’affichent aucune erreur, consultez Pourquoi mon formulaire d’inscription n’affiche-t-il pas les erreurs de mot de passe ?
Ce que Proxy Mail QA ne fait pas ici
- Choisir votre politique, ou vous dire si elle respecte une loi ou une norme qui s’impose à vous.
- Vérifier comment les mots de passe sont stockés, ou tester le reste de votre sécurité. C’est le rôle d’un audit de sécurité ou d’un test d’intrusion.
- Tester une liste de blocage de mots de passe divulgués : essayez vous-même quelques mots de passe connus, comme
password1234567.
Sources : NIST SP 800-63B-4, et sa section sur les authentificateurs.