Entropie d'un mot de passe : ce qu'un indicateur de robustesse ne peut pas savoir

L'entropie appartient au générateur, pas à la chaîne

Demander combien d'entropie contient la chaîne correct-horse-battery-staple, c'est déjà mal poser la question. Si quatre mots ont été tirés aux dés dans une liste publiée de 7 776 mots, la réponse est 51,70 bits. Si quelqu'un les a lus dans une bande dessinée célèbre et recopiés, la réponse frôle zéro, car les tout premiers essais d'un attaquant contiendront exactement cette phrase. Mêmes caractères, même longueur, mêmes classes — sécurité totalement différente, parce que l'entropie mesure combien d'issues également probables le processus aurait pu produire, et que la chaîne ne dit rien du processus.

C'est pourquoi toute la discipline parle de mots de passe générés. Un gestionnaire qui puise dans une source aléatoire cryptographique connaît R et L : il peut annoncer l'entropie exacte. Un humain au clavier n'a pas de R bien défini, car les choix humains ne sont pas uniformes : certaines lettres, certaines substitutions, certaines années et certains motifs de clavier sont bien plus probables que d'autres, et tout outil de cassage sérieux est bâti sur ce déséquilibre précis. Tout chiffre attaché à un mot de passe choisi par un humain est une conjecture sur la façon dont le modèle de l'attaquant colle aux habitudes de cet humain.

La formule, et la condition qui l'accompagne

H = L x log2(R). Le logarithme convertit un nombre de possibilités en bits, et la multiplication par la longueur fonctionne parce que chaque tirage indépendant ajoute ses propres bits. log2(94) = 6,5546 : chaque caractère ASCII imprimable aléatoire supplémentaire ajoute 6,5546 bits. log2(26) = 4,7004 : une lettre minuscule en ajoute moins. log2(7 776) = 12,9248 : un mot Diceware ajoute presque le double d'un caractère aléatoire — 7 776 vaut 6^5, cinq lancers de dé, d'où la taille exacte de la liste.

La condition, c'est une sélection aléatoire uniforme et indépendante, et c'est elle qui fait tout le travail. Brise-la et la formule cesse silencieusement de s'appliquer tout en continuant à renvoyer un chiffre rassurant. Choisis un mot qui te plaît au lieu de lancer les dés : R ne vaut plus 7 776. Mets une majuscule à la première lettre parce qu'une règle l'exige : cette majuscule n'ajoute aucune entropie, puisque tout le monde fait pareil. Ajoute un point d'exclamation et une année : ces caractères allongent L sur le papier tandis que le jeu de règles de l'attaquant les génère gratuitement. La formule ignore tout cela. On ne lui a jamais dit quel était le processus.

Une troisième grandeur s'emmêle avec ces deux-là, et il vaut la peine de la séparer. L'entropie de Shannon d'une chaîne, ce que calcule un calculateur d'entropie générique, mesure la distribution des symboles à l'intérieur de cette chaîne précise. Pour P@ssw0rd123! elle vaut 3,4183 bits par caractère, car certains caractères se répètent. Ce nombre est réellement utile pour la compression et pour repérer des blocs chiffrés, et il ne dit strictement rien sur la difficulté à deviner le mot de passe. Trois questions différentes, trois nombres différents, et les confondre est à l'origine de beaucoup de mauvais conseils.

Ce que l'indicateur mesure réellement

L'indicateur de robustesse classique compte les classes de caractères. Minuscule présente, majuscule présente, chiffre présent, symbole présent : quatre coches, R = 94, on multiplie par la longueur et on affiche une barre rassurante. Donne-lui P@ssw0rd123! : il calcule 12 x 6,5546 = 78,66 bits et déclare le mot de passe excellent. Donne-lui les douze caractères réellement aléatoires que ton gestionnaire vient de produire : il calcule exactement les mêmes 78,66 bits. L'indicateur ne peut pas les distinguer, car il n'a jamais regardé que les classes présentes.

Un attaquant ne procède jamais ainsi. Le cassage réel passe une liste de mots dans un fichier de règles : règles qui mettent une majuscule, qui remplacent a par @, o par 0 et s par $, qui ajoutent des années à deux ou quatre chiffres et un point d'exclamation final, qui inversent, dupliquent, tronquent. Chaque transformation dans P@ssw0rd123! est une règle standard. Prends une liste de dix millions d'entrées et dix mille règles : l'espace de candidats vaut 10^11 — environ 36,5 bits, épuisé en une seconde à cent milliards d'essais par seconde. Face aux 78,66 bits de l'indicateur, c'est une surestimation de 42,11 bits, un facteur de 4 760 milliards.

De meilleurs indicateurs existent, sur un principe différent. Au lieu de compter des classes, ils tentent de reconstituer la façon dont le mot de passe a probablement été construit, en le confrontant à des dictionnaires, des prénoms courants, des dates, des parcours de clavier et des répétitions, puis estiment combien d'essais coûterait la reconstitution la moins chère. C'est un chiffre bien plus honnête, et il ne voit toujours que les motifs qu'on lui a appris. La conclusion prudente : un indicateur est un filtre contre le manifestement catastrophique, pas une mesure. Si tu veux un chiffre fiable, génère le mot de passe et compte les bits que le générateur a réellement dépensés.

Plus long ne veut pas dire plus solide

Deux exemples calculés tranchent la question. Seize lettres minuscules aléatoires donnent 16 x 4,7004 = 75,21 bits. Douze caractères ASCII imprimables aléatoires donnent 12 x 6,5546 = 78,66. La chaîne de seize caractères est un tiers plus longue et 3,45 bits plus faible — environ onze fois plus facile à deviner. Longueur et alphabet s'échangent l'un contre l'autre, et seul leur produit compte.

L'écart se creuse avec les phrases de passe. Une phrase Diceware de quatre mots dépasse facilement vingt caractères et ne porte pourtant que 51,70 bits, contre 78,66 pour le mot de passe aléatoire de douze caractères. Soit 26,96 bits de moins, un facteur de 130 millions. Les phrases de passe ne sont pas faibles — elles sont merveilleusement mémorisables, et une phrase de six mots atteint 77,55 bits, à égalité de fait avec les douze caractères aléatoires. Mais la robustesse vient du nombre de mots tirés, pas du nombre de lettres tapées, et quatre mots ne suffisent pas pour ce qui te tient à cœur.

Le temps de cassage est le chiffre du défenseur, pas le vôtre

Convertir l'entropie en durée exige une entrée de plus : la vitesse à laquelle l'attaquant teste les candidats. En moyenne, il trouve le mot de passe après la moitié de l'espace de clés : le temps attendu vaut donc 2^(H-1) divisé par le taux d'essais. Tout dépend de ce taux, et toi, utilisateur, tu ne le contrôles pas. C'est le service qui stocke ton mot de passe qui le contrôle.

Prends la phrase Diceware de quatre mots, 51,70 bits, et ne fais varier que le choix de stockage du défenseur. Face à un hachage rapide non salé où une baie de GPU tient 10^11 essais par seconde, le temps attendu est de 5,1 heures. Face à bcrypt au coût 12, où la même baie tient peut-être 10^4 par seconde, il est de 5 790 ans. Face à Argon2id réglé sur 64 Mio de mémoire, où l'exigence mémoire bloque le parallélisme massif et le taux tombe vers 10^3, il est de 57 900 ans. Mot de passe identique. Entropie identique. Sept ordres de grandeur d'écart, décidés entièrement par quelqu'un d'autre.

C'est là le lien entre cet article et toute discussion sur les fonctions de hachage. MD5 et SHA-256 ont été conçus pour le débit et le tiennent — plus d'un gigaoctet par seconde sur un seul cœur — ce qui les rend précisément inadaptés au stockage de mots de passe. Argon2id, bcrypt et scrypt dépensent volontairement du temps et de la mémoire réels par essai. Quand tu lis un titre affirmant qu'un mot de passe se casse en tant d'heures, la première question est : quel hachage l'affirmation supposait-elle ? Car cette seule hypothèse déplace la réponse d'un facteur dix millions.

La réutilisation bat l'entropie à tous les coups

Toute cette arithmétique ne sert à rien si le mot de passe a déjà été publié. Le bourrage d'identifiants ne devine rien : il reprend des paires identifiant/mot de passe issues d'une fuite et les rejoue sur tous les autres services, et cela fonctionne parce que la réutilisation est courante. Un mot de passe de 78,66 bits réutilisé sur deux sites vaut 78,66 bits chez celui qui le stocke correctement et zéro chez celui qui l'a perdu en clair — après quoi il vaut zéro partout. L'entropie n'a jamais été le point de rupture.

D'où la teneur des recommandations actuelles du NIST. La SP 800-63B a abandonné les anciennes règles de composition — majuscule obligatoire, symbole obligatoire, rotation forcée tous les quatre-vingt-dix jours — parce qu'elles poussent les gens vers des motifs prévisibles sans acheter de vraie entropie. Elle recommande à la place une longueur minimale généreuse, aucun maximum arbitraire, aucune troncature, et le filtrage des mots de passe candidats contre des listes de valeurs connues comme compromises. C'est ce dernier point qui attrape P@ssw0rd123!, ce qu'aucun calcul d'entropie n'aurait fait.

Ce qu'il faut faire concrètement

Génère, n'invente pas. Un gestionnaire de mots de passe puisant dans une source aléatoire cryptographique est le seul moyen de connaître ton entropie plutôt que de l'espérer, et il supprime du même coup le problème de la réutilisation. Pour la poignée de secrets que tu dois taper de mémoire — le mot de passe maître du gestionnaire, une phrase de chiffrement de disque, un déverrouillage d'appareil — utilise une phrase Diceware de six mots à 77,55 bits, mémorisable et hors d'atteinte des attaques par liste de mots. Vise au moins 75 bits pour tout ce qui garde d'autres identifiants, et considère 50 bits comme le plancher d'un compte ordinaire protégé par limitation de débit et second facteur.

Et construis correctement l'autre côté, car en tant que développeur tu es le défenseur dont le choix décide des chiffres du tableau ci-dessus. Stocke les mots de passe avec Argon2id quand tu le peux, bcrypt ou scrypt sinon, toujours avec un sel unique. N'impose pas de longueur maximale et ne tronque pas en silence. N'impose pas de rotation périodique. Filtre les nouveaux mots de passe contre une liste de mots de passe compromis. Ajoute un second facteur : il vaut plus de bits que toute politique de mot de passe n'en extraira jamais de tes utilisateurs.

Questions fréquentes

Combien de bits d'entropie faut-il à un mot de passe ?

Cela dépend de la façon dont l'autre bout le stocke, et c'est la part inconfortable de la réponse. Prends 51,70 bits, l'entropie d'une phrase Diceware de quatre mots. Face à un hachage rapide non salé à 10^11 essais par seconde, le temps attendu pour la trouver est de 5,1 heures — inutile. Face à bcrypt au coût 12, environ 10^4 essais par seconde, le même mot de passe tient 5 790 ans. Aucun seuil unique n'est donc juste partout. Cibles pratiques : au moins 75 bits pour tout ce qui protège d'autres identifiants, comme le secret maître d'un gestionnaire ou une phrase de chiffrement de disque, car ceux-là doivent survivre à une attaque hors ligne sur une copie des données. Environ 50 bits se défend pour un compte ordinaire derrière une limitation de débit côté serveur et un second facteur, où l'attaquant ne devine jamais vite. En termes générés, 75 bits, c'est douze caractères ASCII imprimables aléatoires (78,66) ou six mots Diceware (77,55) ; 50 bits, c'est quatre mots Diceware (51,70) ou huit caractères aléatoires (52,44).

Une phrase de passe est-elle plus solide qu'un mot de passe aléatoire ?

Pas automatiquement, et le nombre de caractères est un mauvais guide. Une phrase Diceware de quatre mots porte 4 x log2(7 776) = 51,70 bits même si elle dépasse vingt caractères. Douze caractères ASCII imprimables aléatoires portent 12 x log2(94) = 78,66 bits dans bien moins de place. La phrase est 26,96 bits plus faible, soit un facteur de 130 millions dans l'effort de devinette — une chaîne plus longue et bien plus facile à trouver. Ajoute des mots et le tableau change : six mots donnent 77,55 bits, à égalité de fait avec les douze caractères aléatoires, et sept donnent 90,47. Le vrai avantage d'une phrase de passe est que tu la gardes en tête, ce qui compte énormément pour les deux ou trois secrets que tu tapes de mémoire et pas du tout pour la centaine que ton gestionnaire remplit. Deux conditions : les mots doivent être tirés au hasard dans une liste publiée, pas choisis par toi, et la taille de la liste doit être connue pour que R soit réel. Choisir quatre mots qui te plaisent n'est pas du Diceware et n'a pas d'entropie définie.

Pourquoi mon gestionnaire note-t-il un mot de passe autrement que le site ?

Parce qu'ils répondent à des questions différentes. Un indicateur de site compte typiquement les classes de caractères et multiplie par la longueur, ce qui donne à P@ssw0rd123! et à douze caractères réellement aléatoires les mêmes 78,66 bits — il ne peut pas les distinguer, n'ayant regardé que les classes présentes. Un estimateur par motifs tente au contraire de reconstituer la fabrication probable du mot de passe, en le confrontant à des dictionnaires, prénoms, dates, parcours de clavier et répétitions, et rapporte combien d'essais coûterait la reconstitution la moins chère. Pour P@ssw0rd123!, c'est bien plus bas, car chaque transformation qu'il contient est une règle de cassage standard : une liste de dix millions de mots croisée avec dix mille règles fait 10^11 candidats, environ 36,5 bits. L'écart entre les deux verdicts est de 42,11 bits, un facteur de 4 760 milliards. Crois le pessimiste. Et note qu'aucun des deux ne peut mieux noter un mot de passe généré aléatoirement que la formule, car pour un mot de passe généré la formule est exacte — c'est toute la raison de générer plutôt qu'inventer.

Ajouter un symbole et un chiffre aide-t-il vraiment ?

Cela aide quand le caractère a été tiré au hasard, et ne sert à rien quand il a été choisi comme tout le monde le choisit. Élargir l'alphabet augmente bien le rendement par caractère : log2(26) = 4,7004 bits pour les minuscules contre log2(94) = 6,5546 pour l'ASCII imprimable complet, soit 1,85 bit de plus par caractère aléatoire. Mais une majuscule à la première lettre et un point d'exclamation à la fin, c'est ce que fait presque tout le monde : le jeu de règles de l'attaquant produit ces variantes gratuitement et le gain réel d'entropie est proche de zéro. C'est pourquoi la NIST SP 800-63B a abandonné les règles de composition obligatoires : elles imposent une transformation prévisible au lieu d'ajouter du hasard. Si tu veux plus de bits, allonge le mot de passe ou élargis réellement l'alphabet au hasard — seize lettres minuscules aléatoires atteignent déjà 75,21 bits sans aucun symbole, et douze caractères aléatoires parmi les 94 atteignent 78,66. Les deux battent n'importe quelle décoration d'un mot mémorisable.

En quoi l'entropie d'un mot de passe diffère-t-elle de l'entropie de Shannon ?

Elles mesurent des objets différents, et un calculateur d'entropie générique te donnera volontiers le mauvais. L'entropie de Shannon d'une chaîne mesure la distribution des symboles à l'intérieur de cette chaîne : pour P@ssw0rd123! elle vaut 3,4183 bits par caractère, entièrement déterminée par les caractères qui se répètent. C'est le bon outil pour estimer la compressibilité de données ou repérer un bloc chiffré au milieu de texte clair, et cela ne dit rien de la devinabilité. L'entropie d'un mot de passe mesure le processus générateur — combien de mots de passe également probables la procédure aurait pu produire — soit H = L x log2(R) quand la sélection était vraiment uniforme et aléatoire. Les deux peuvent diverger énormément : un mot de passe aléatoire de 12 caractères et P@ssw0rd123! ont le même H par la formule, 78,66 bits, alors que leurs entropies de Shannon diffèrent et leur résistance réelle diffère de dizaines de bits. Si tu choisis un mot de passe, c'est le processus générateur qui compte.

Puis-je simplement allonger mon mot de passe au lieu de le rendre aléatoire ?

La longueur ne se convertit en entropie que si les caractères ajoutés étaient imprévisibles. Rallonger un mot mémorisable avec une année de naissance et une ponctuation allonge L sur le papier tandis que le fichier de règles de l'attaquant génère exactement ces terminaisons gratuitement : H = L x log2(R) ne décrit alors plus rien de réel — l'espace de recherche pratique reste de l'ordre de la liste de mots multipliée par le jeu de règles, environ 10^11 candidats ou 36,5 bits, soit une seconde de travail à cent milliards d'essais par seconde. La longueur appliquée à du matériel réellement aléatoire est le levier le plus efficace dont tu disposes : chaque minuscule aléatoire ajoute log2(26) = 4,7004 bits et chaque caractère ASCII imprimable aléatoire ajoute log2(94) = 6,5546. Seize minuscules aléatoires atteignent 75,21 bits — aucun symbole, aucune majuscule, aucune substitution, et bien plus solide que n'importe quel mot de dictionnaire décoré. Alors oui, allonge, mais seulement si la longueur ajoutée est aléatoire. Si tu dois le mémoriser, ajoute des mots Diceware plutôt que des caractères : chacun vaut 12,9248 bits.