Entropie des mots de passe : les vrais maths qui expliquent pourquoi la longueur bat la complexité

Les conseils sur les mots de passe sont restés bloqués depuis vingt ans sur une variante de « utilisez des majuscules, des minuscules, un chiffre et un symbole ». Les maths disent que c’est en grande partie faux — ou du moins très mal hiérarchisé. La force d’un mot de passe généré aléatoirement est régie par une seule formule, et cette formule récompense la longueur bien plus agressivement que la taille de l’ensemble de caractères. C’est aussi, et ce n’est pas une coïncidence, ce que le NIST affirme depuis le SP 800-63B (2017, révisé en 2024).

Cet article parcourt les maths réelles, calcule des valeurs d’entropie concrètes, donne des estimations de force brute avec des hypothèses explicitement énoncées, puis traduit tout cela en règles applicables.

La formule d’entropie

Pour un mot de passe tiré uniformément au hasard dans un ensemble de caractères de taille P, de longueur L, le nombre de mots de passe possibles est P^L, et l’entropie en bits est :

H = log2(P^L) = L × log2(P)

C’est tout le modèle. L’entropie mesure la taille de l’espace de recherche qu’un attaquant doit énumérer. Chaque bit supplémentaire double le travail.

Les deux leviers sont P (taille de l’ensemble) et L (longueur), et ils ne sont pas égaux. Ajouter un caractère multiplie l’espace de recherche par P ; élargir l’ensemble le multiplie par un ratio. Voici les ensembles qui comptent et leur contribution d’entropie par caractère :

Ensemble de caractères	Taille (P)	Bits par caractère, log2(P)
Chiffres uniquement (`0–9`)	10	3.32
Lettres minuscules (`a–z`)	26	4.70
Minuscules + majuscules (`a–zA–Z`)	52	5.70
Alphanumérique (`a–zA–Z0–9`)	62	5.95
ASCII imprimable complet (94 caractères, symboles inclus)	94	6.55

Notez les rendements décroissants de l’élargissement de l’ensemble : passer des minuscules seules (26) à l’ensemble imprimable complet (94) quadruple presque l’ensemble, mais ne fait passer l’entropie par caractère que de 4.70 à 6.55 bits — un gain de 39 % par caractère. Passer de 8 à 16 caractères, quelle que soit la taille de l’ensemble, double exactement l’entropie. La longueur croît linéairement sans plafond ; la taille de l’ensemble est limitée à ~94 sur un clavier standard.

Valeurs d’entropie réelles, calculées

En appliquant H = L × log2(P) :

Ensemble ASCII imprimable complet (94 caractères) :

Longueur	Entropie (bits)	Espace de recherche
8	52.4	~6.1 × 10^15
10	65.5	~4.4 × 10^19
12	78.7	~4.8 × 10^23
14	91.8	~5.1 × 10^27
16	104.9	~3.7 × 10^31
20	131.1	~2.9 × 10^39

Ensemble minuscules uniquement (26 caractères) :

Longueur	Entropie (bits)
8	37.6
12	56.4
16	75.2
20	94.0

Ensemble alphanumérique (62 caractères) :

Longueur	Entropie (bits)
8	47.6
12	71.5
16	95.3
20	119.1

Voici maintenant la comparaison qui illustre le propos. Regardez ces trois mots de passe, tous des productions plausibles de politiques différentes :

xQ9#mK2! — 8 caractères, ensemble complet de 94 caractères : 52.4 bits
hkbwvztdpqrm — 12 caractères, minuscules uniquement : 56.4 bits
hkbwvztdpqrmjfyc — 16 caractères, minuscules uniquement : 75.2 bits

Le mot de passe « simple » de 12 caractères en minuscules bat déjà celui de 8 caractères « complexe », et celui de 16 caractères en minuscules le bat de 23 bits — un facteur d’environ 8 millions dans l’espace de recherche — tout en étant nettement plus facile à taper et à retenir. Quatre caractères de plus valent plus que l’ensemble complet des symboles.

C’est en ce sens que la longueur bat la complexité : non pas que la complexité soit inutile (un ensemble plus large aide toujours à longueur fixe), mais que les humains sont incapables de produire de la complexité de façon aléatoire, et que l’entropie marginale par caractère ajouté dépasse l’entropie marginale par élargissement de l’ensemble pour tout ensemble réaliste.

L’énorme réserve : cela ne marche que pour les mots de passe aléatoires

La formule H = L × log2(P) suppose un tirage uniformément aléatoire. Les mots de passe choisis par des humains n’ont rien de tel. Summer2026! fait 11 caractères tirés d’un ensemble d’environ 90 caractères — nominalement ~71 bits — mais n’importe quel outil de cassage l’essaie dans ses premiers milliers de tentatives, parce que c’est un mot du dictionnaire, une année et le symbole le plus courant, dans l’arrangement le plus courant.

L’entropie des mots de passe humains est dominée par la prévisibilité, pas par la formule. Les analyses empiriques de corpus de mots de passe ayant fuité montrent régulièrement qu’un petit dictionnaire de mots de passe courants, assorti de règles de déformation (majuscule en tête, chiffres en fin, ! ajouté), couvre une large fraction des mots de passe réels. C’est pourquoi :

Les maths de l’entropie s’appliquent aux mots de passe générés, aux phrases de passe issues de listes de mots et aux secrets créés par un gestionnaire — pas à ce qu’une personne invente seule.
Pour les mots de passe choisis par des humains, la défense n’est pas l’estimation d’entropie, c’est le filtrage contre les listes de mots de passe courants et déjà compromis — exactement ce que le NIST impose.

Phrases de passe et Diceware

La méthode Diceware rend les maths concrètes pour des secrets mémorisables : lancez des dés pour choisir des mots uniformément dans une liste de 7 776 mots (6^5). Chaque mot porte log2(7776) ≈ 12.9 bits :

5 mots : 64.6 bits
6 mots : 77.5 bits
7 mots : 90.4 bits

Une phrase de passe de 6 mots dans le style correct horse battery staple (le célèbre exemple du XKCD illustre les mêmes maths) donne ~77 bits avec une mémorisabilité bien meilleure qu’une chaîne aléatoire de 12 caractères à 78.7 bits. Même niveau de sécurité, utilisabilité radicalement différente.

Estimations de temps de force brute — avec les hypothèses énoncées

Tout chiffre de « temps de cassage » est dénué de sens sans son modèle d’attaque. En voici un, explicitement énoncé :

Hypothèses : attaque hors ligne contre un hachage rapide et non salé (par exemple MD5/SHA-1 brut) à 10^10 (10 milliards) de tentatives par seconde — atteignable avec un modeste montage multi-GPU. Recherche exhaustive de tout l’espace ; le temps attendu pour trouver le mot de passe est la moitié. Pas de limitation de débit, pas de raccourci via des listes de fuites (valide car nous supposons des mots de passe aléatoires).

Classe de mot de passe	Espace de recherche	Temps exhaustif @ 10^10/s
8 caractères, minuscules (26)	2.1 × 10^11	~21 secondes
8 caractères, ensemble complet (94)	6.1 × 10^15	~7 jours
12 caractères, minuscules (26)	9.5 × 10^16	~110 jours
12 caractères, ensemble complet (94)	4.8 × 10^23	~1.5 million d’années
16 caractères, minuscules (26)	4.4 × 10^22	~140 000 ans
16 caractères, ensemble complet (94)	3.7 × 10^31	~1.2 × 10^14 ans

Considérez-les comme des ordres de grandeur illustratifs, pas des garanties. Ils varient dans les deux sens :

Plus lent en pratique si le site utilise une vraie fonction de hachage de mots de passe. bcrypt, scrypt ou Argon2 avec des paramètres raisonnables peuvent réduire le débit de tentatives de 4 à 7 ordres de grandeur par rapport à MD5 brut, transformant « ~7 jours » en « plus long que n’importe quel horizon dont quiconque se soucie ». C’est pourquoi le choix de l’algorithme de hachage compte plus que presque tout ce que font les utilisateurs.
Plus rapide si le mot de passe n’est pas aléatoire (attaque par dictionnaire), si l’attaquant dispose de matériel d’État, ou si des progrès de type loi de Moore se cumulent pendant les années où un hachage volé garde de la valeur.
Les attaques en ligne (tentatives contre un point d’entrée de connexion actif) relèvent d’un tout autre modèle : les limites de débit et les verrouillages plafonnent les attaquants à peut-être quelques centaines de tentatives, si bien que même des secrets de ~20 bits survivent — c’est pourquoi le NIST exige la limitation de débit, et pourquoi les mots de passe par site de votre gestionnaire comptent plus que la force de n’importe quel mot de passe isolé.

La leçon pratique du tableau : 8 caractères ne suffisent pour rien de ce qui sera haché rapidement, point final ; 12 caractères aléatoires et plus, c’est confortable ; 16, c’est exagéré dans le bon sens. Et encore une fois, la chaîne de 16 caractères en minuscules survit plus longtemps que celle de 12 caractères en ensemble complet — la longueur gagne.

Ce que dit réellement le NIST SP 800-63B

Les Digital Identity Guidelines du NIST (SP 800-63B, initialement en 2017 ; révision 4 publiée en 2024) ont inscrit une grande partie de tout cela dans la politique fédérale américaine. Les recommandations structurantes pour les vérificateurs de mots de passe (« secrets mémorisés ») :

Longueur minimale, pas complexité. Exiger au moins 8 caractères pour les mots de passe choisis par l’utilisateur (la révision 4 porte ce minimum à 15 pour les mots de passe utilisés comme facteur unique, 8 lorsqu’un second facteur est présent). Autoriser au moins 64 caractères. Ne pas imposer de règles de composition (pas de « doit contenir une majuscule, un chiffre, un symbole ») — elles poussent les utilisateurs vers des schémas prévisibles (Password1!) qui affaiblissent la sécurité réelle.
Pas de changement périodique forcé. La révision de 2017 avait déjà abandonné le vieux dogme du « renouvellement tous les 90 jours » ; la révision 4 le confirme. Ne changez les mots de passe qu’en cas de preuve de compromission. La rotation forcée produit immanquablement Summer2026! → Autumn2026! — un incrément qu’une règle de cassage couvre trivialement.
Filtrage contre les listes de mots de passe compromis et courants. Les vérificateurs doivent comparer les mots de passe candidats à des dictionnaires de mots de passe connus comme compromis, à des mots du dictionnaire, à des chaînes répétitives ou séquentielles, et à des mots liés au contexte (nom du service, nom d’utilisateur). Cela remplace les règles de composition comme véritable défense des secrets choisis par des humains.
Autoriser le collage et les gestionnaires de mots de passe. Les vérificateurs doivent permettre la saisie collée — ce qui constitue une approbation explicite des gestionnaires de mots de passe, puisque des chaînes aléatoires générées de 20 caractères sont exactement ce que les lignes directrices veulent voir entre les mains des utilisateurs.
Pas d’indices ni de questions de sécurité fondés sur la connaissance. Les indices de mot de passe et la KBA (« nom de jeune fille de la mère ») sont interdits car ils fuient ou révèlent trivialement le secret.
Hachage salé et dur en mémoire pour le stockage. Les vérificateurs doivent stocker les mots de passe hachés avec une fonction à sens unique appropriée — les recommandations pointent vers des schémas comme Argon2, bcrypt ou PBKDF2 avec des facteurs de travail adéquats — avec un sel par utilisateur d’au moins 32 bits.

Remarquez comme tout cela s’accorde avec les maths de l’entropie : les règles de composition n’ajoutent pas d’entropie réelle pour les humains, la longueur si ; la rotation détruit l’entropie que les utilisateurs avaient en les poussant vers des schémas ; et le filtrage par listes de fuites gère le fait que l’entropie humaine est incommensurable. La norme, c’est les maths institutionnalisées.

Des règles réellement applicables

Laissez un générateur créer vos mots de passe. La génération aléatoire est la seule façon pour que la formule d’entropie s’applique à vous. Notre générateur de mots de passe crée des mots de passe cryptographiquement aléatoires dans votre navigateur — rien n’est transmis nulle part. Réglez-le sur 16 caractères et plus, et n’y pensez plus.
16 caractères par défaut pour tout ce qui compte. À plus de 95 bits même en minuscules uniquement, vous êtes au-delà de tout budget de force brute concevable contre un stockage correctement haché.
Pour ce que vous devez mémoriser, utilisez une phrase de passe de 6 mots. ~77 bits, tapable, mémorisable. Générez des candidats avec le mode phrase de passe/liste de mots du même outil s’il est disponible, ou utilisez Diceware.
Unique par site, toujours. L’entropie protège un site ; la réutilisation transforme une fuite en toutes les fuites. C’est à cela que sert le gestionnaire de mots de passe.
Ajoutez un second facteur lorsqu’il est proposé. Les exigences de longueur du NIST s’assouplissent explicitement en présence de MFA, car un second facteur multiplie le travail de l’attaquant bien plus économiquement que davantage d’entropie de mot de passe.
Ignorez le théâtre de la complexité. Un site exigeant « une majuscule, un chiffre, un symbole » mais vous plafonnant à 12 caractères a sa politique à l’envers. Conformez-vous mécaniquement, mais ne confondez pas cela avec de la force.

Résumé

L’entropie d’un mot de passe aléatoire est H = L × log2(P) : chaque caractère ajoute un nombre fixe de bits qui ne dépend que de la taille de l’ensemble.
L’élargissement de l’ensemble (26 → 94 caractères) gagne ~1.85 bit par caractère ; chaque caractère ajouté gagne 4.7 à 6.6 bits. La longueur gagne nettement.
8 caractères aléatoires ≈ 52 bits ≈ quelques jours de cassage contre des hachages hors ligne rapides ; 12 caractères aléatoires ≈ 78 bits et plus ≈ incassable en pratique dans ce modèle.
La formule ne s’applique qu’à la génération aléatoire. Les mots de passe choisis par des humains sont vaincus par les dictionnaires, c’est pourquoi le NIST impose le filtrage par listes de fuites et interdit les règles de composition et la rotation forcée.
Générez des mots de passe aléatoires de 16 caractères avec le générateur de mots de passe, stockez-les dans un gestionnaire et activez le MFA. Cette pile est ce que les maths recommandent.