Ce qu’une liste locale de mots de passe faibles peut prouver — et pourquoi ce n’est pas une recherche de fuites mondiale

Un testeur qui affiche « absent de la liste de mots de passe faibles » se lit trop vite comme « ce mot de passe n’est jamais apparu dans une fuite ». Ce n’est pas la même phrase. Une liste courte, téléchargée avec la page, répond seulement à « est-ce un secret déjà trop utilisé ». Have I Been Pwned répond à une autre question, par un autre chemin de données. La suite resserre la phrase que vous pouvez écrire, et donne un contrôle à finir dans les outils de développement.

« Absent de la liste » n’est pas « jamais fuité »

La plupart des contrôles locaux n’ont que deux issues : une correspondance, ou rien. La correspondance se lit sans effort. La chaîne figure déjà dans une liste publique de mots de passe fréquents ; la garder, c’est rester dans le premier lot qu’un attaquant essaie. L’absence, elle, se charge souvent d’une deuxième affirmation : la liste « vient des fuites », donc rien trouvé voudrait dire « propre ».

Une liste ne parle que des lignes qu’elle contient. Une fuite interne jamais publiée, un journal d’infostealer qu’aucun corpus public n’a encore absorbé, ou un mot de passe volé sur un petit site et jamais republié, n’apparaîtront pas dans les quelques centaines ou milliers de lignes qu’un onglet vient de télécharger. La lecture honnête d’une absence est : avec cette liste locale et cette règle de comparaison, la chaîne exacte — ou les quelques variantes que le script sait essayer — n’a pas été trouvée. Cette phrase n’a jamais promis « tout le web ».

Écrivez cette limite avant de décider la suite. Une correspondance justifie de changer le mot de passe. Une absence laisse encore la longueur, la réutilisation, et la question de savoir si un gestionnaire l’a tiré au hasard. La liste est un filtre. Ce n’est pas un certificat de propreté.

Contre quel type d’essais la liste sert

Les attaquants partent rarement de a jusqu’à zzzz…. Les deux chemins courants sont le bourrage d’identifiants — réessayer un couple identifiant / mot de passe déjà fuité sur d’autres sites — et les essais en ligne qui commencent en tête des classements publics de mots faibles. 123456, password et qwerty occupent le haut de ces classements parce que les gens les choisissent encore, pas parce qu’ils « ont l’air courts ». Quelques essais suffisent souvent.

Une liste de mots fréquents vise cette couche. Elle marque les chaînes déjà trop utilisées, tant que vous pouvez encore les changer. Elle ne dit pas quelle est la taille de l’espace de recherche, et elle ne dit pas si un corpus encore privé contient déjà cette ligne. Ce sont l’estimation d’entropie et un corpus de fuites bien plus large. On ne doit pas les fondre avec « cela ressemble-t-il à un mot de passe faible courant » en un seul verdict.

C’est aussi pourquoi une liste qui n’est pas très longue reste utile. Les connexions en ligne sont presque toujours limitées en nombre d’essais. L’attaquant a un budget serré avant le verrouillage, donc il commence par les mots les mieux classés. Le NIST SP 800-63B-4 écrit que le rôle d’une liste de blocage (blocklist) est d’arrêter les mots de passe qu’on a de bonnes chances de deviner avant que le bridage n’intervienne. Une fois la liste assez grande pour cet objectif, les lignes supplémentaires rapportent peu, parce que l’attaque en ligne est déjà bridée. Une liste locale de mots fréquents est faite pour cet objectif. Elle n’est pas conçue pour contenir chaque mot de passe qui a un jour fuité.

Le NIST veut comparer la chaîne entière, pas ajouter des règles de complexité

Le National Institute of Standards and Technology des États-Unis, dans le SP 800-63B-4, écrit la comparaison comme une étape obligatoire pour la partie qui accepte un mot de passe : à la création ou au changement, le candidat entier doit être confronté à une liste de blocage de secrets courants, prévisibles ou déjà compromis. Le contrôle n’est pas « contient-il un mot du dictionnaire » ni « manque-t-il un symbole ». Une correspondance doit être refusée, et l’utilisateur doit savoir pourquoi.

La même section réécrit la politique de mot de passe mal comprise depuis plus de dix ans. Les vérifieurs ne doivent plus exiger un mélange de majuscules, de chiffres et de symboles. Ils ne doivent plus imposer un changement périodique, sauf s’il existe des indices que cet authentifiant a été compromis. Un mot de passe utilisé comme seul facteur doit faire au moins 15 caractères ; comme un facteur parmi d’autres, le plancher est 8. Ces phrases visent les sites qui acceptent des mots de passe, pas une page d’auto-contrôle dans le navigateur. Elles aident pourtant quiconque lit un résultat : cocher des cases de complexité ne prouve rien. La première chose à bloquer, c’est une chaîne entière déjà présente dans une liste publique.

Le NIST rappelle aussi de donner une consigne après un refus, pour que l’utilisateur ne s’arrête pas à réécrire password en Password1. Si une liste locale essaie aussi le repli de casse, deux ou trois chiffres en suffixe, et le leet courant (@ pour a, 0 pour o), c’est précisément cette réécriture qu’elle vise. Ce reste une heuristique, pas une preuve cryptographique. P@ssw0rd2026! peut être attrapé. Une variante que les règles n’encodent pas ne le sera pas.

N’utilisez pas un mot de passe encore en service pour cet essai. Pour comparer une liste, prenez un ancien secret déjà abandonné, ou une chaîne jetable. On vérifie la règle et le trafic, on ne réexpose pas un identifiant vivant.

Liste locale courte, requête par préfixe de hachage, corpus hors ligne

« Est-ce que cela a fuité ? » recouvre au moins trois méthodes. Les mélanger, et une absence devient « jamais fuité ». La différence n’est pas le slogan. C’est quelles données quittent l’appareil, et ce qu’un serveur peut voir.

La première méthode est une liste locale courte. La page télécharge un fichier texte public dans l’onglet courant, le script construit un ensemble en mémoire, puis cherche la chaîne entière saisie et quelques variantes. La requête sortante, c’est le fichier de liste, pas le mot de passe testé. La couverture égale le nombre de lignes non vides. Prenez le fichier leaked-top10k.txt livré avec le testeur MakePwd. Le nom dit top10k. Ouvrez la réponse et comptez les lignes vous-même : aujourd’hui, ce fichier a un peu plus de 800 entrées fréquentes, pas 10 000, et encore moins tout le web. Si le chargement échoue, l’implémentation retombe sur un tout petit ensemble intégré (par exemple password et 123456). La couverture se rétrécit. Le contrôle reste sur cet appareil.

La deuxième méthode est la requête par plage de Pwned Passwords, chez Have I Been Pwned. La documentation officielle décrit le corpus comme des centaines de millions de mots de passe déjà apparus dans des fuites. Le client calcule localement un SHA-1 (ou NTLM) et n’envoie que les cinq premiers caractères hexadécimaux à https://api.pwnedpasswords.com/range/{prefix}. Il compare ensuite les suffixes renvoyés au hachage complet déjà calculé. Par conception, ni le clair ni le hachage entier ne partent. C’est du k-anonymat : le serveur sait seulement dans lequel d’environ un million de seaux de préfixe vous êtes tombé (165). C’est malgré tout une requête externe. Ce qui est interrogé n’est pas le mot de passe lui-même. En novembre 2025, HIBP a intégré environ 1,3 milliard de mots de passe uniques issus du corpus de bourrage Synthient, dont environ 625 millions étaient nouveaux pour ce service. En juin 2026, il a ajouté environ 124 millions de mots uniques provenant de journaux d’infostealer. Ces chiffres montrent un corpus qui grossit. Ils ne veulent pas dire « contrôlé une fois, propre pour toujours ».

La troisième méthode consiste à télécharger le corpus entier sur votre machine ou votre réseau, puis à comparer hors ligne. HIBP publie aussi ce téléchargement. La couverture se rapproche de la deuxième méthode, mais aucun préfixe n’est envoyé à api.pwnedpasswords.com. Le coût, ce sont les mises à jour, le stockage, et l’index de hachage que vous maintenez.

Méthode Ce qui quitte cet appareil Ce qu’une absence peut soutenir
Liste locale de mots fréquents Le fichier de liste ; le mot de passe testé ne devrait pas partir Absent de cette liste (et des variantes implémentées)
Requête par plage HIBP Le préfixe SHA-1 / NTLM de 5 caractères Absent du corpus Pwned Passwords actuel
Corpus hors ligne complet Aucune requête de recherche Absent de la copie que vous avez téléchargée

Aucune de ces trois phrases ne se réécrit en « ce mot de passe n’est jamais apparu dans une fuite ». Les dumps non publiés, les journaux non encore intégrés, et un secret que vous n’avez jamais confié à un tiers restent hors du devoir de chaque collection. La liste locale est la plus étroite des trois. Son avantage : le mot de passe testé n’a pas à quitter l’onglet.

Ce qu’une correspondance et une absence peuvent chacune soutenir

Une correspondance se rédige en phrase ferme : cette chaîne figure déjà dans une liste publique de mots fréquents, ou ce n’est qu’une réécriture que la liste sait reconnaître. Continuer à l’utiliser, c’est rester dans l’ensemble que le bourrage d’identifiants et les essais en ligne tentent en premier. Le bon geste est de la changer, et de ne pas réutiliser la même chaîne ailleurs.

Une absence doit porter un périmètre. Elle soutient « cela ne ressemble pas à un mot de passe faible courant de cette liste ». Elle ne soutient pas « il n’a jamais fuité », « on peut le réutiliser partout », ni « l’entropie suffit ». Un mot de passe aléatoire de 20 caractères sera absent. Un mot apparu seulement dans une fuite non publiée le sera aussi. La pastille sur la page a le même air. Le sens, non.

Il y a aussi le cas qui a l’air long et doit tout de même être marqué faible. Une correspondance l’emporte sur l’entropie. password fait huit lettres, donc une estimation par jeu de caractères produit un nombre de bits non nul, et tout le monde l’essaie quand même en premier. Si un testeur local force la note à « faible » après une correspondance, la raison est la liste, pas une formule de bits cassée. L’inverse vaut aussi. Une absence plus une entropie élevée ne soutient que « cela n’a pas l’air courant, et la force brute a l’air coûteuse ». Ce n’est pas « déjà sûr ». La réutilisation, l’hameçonnage et un site qui stocke le clair restent hors de cette comparaison.

La phrase la plus courte à envoyer à un collègue : une correspondance = changez-le tout de suite ; une absence n’écarte que cette liste. Ensuite, demandez s’il est réutilisé, et s’il a été tiré au hasard.

Contrôler sur place : le fichier de liste, puis Network

« Comparé en local, rien n’est envoyé » ne se prouve pas tout seul. Ce que vous pouvez voir sur place, ce sont deux choses : quel fichier de liste le navigateur a téléchargé, et si la chaîne saisie est partie comme donnée métier.

Commencez par la liste. Ouvrez Network dans les outils de développement, filtrez une requête dont le nom contient leaked ou top, et enregistrez la réponse en texte. Comptez les lignes non vides dans un éditeur. Vérifiez les premières lignes : des mots fréquents publics comme 123456 et password. Le nombre de lignes que vous avez compté, c’est le dénominateur derrière « absent ». N’écrivez pas « 10 000 entrées » parce que le nom de fichier contient 10k.

Puis contrôlez le mot de passe testé. Préparez un canari qui n’apparaîtra jamais dans un vrai flux, par exemple canary-audit-2026-x7k, et saisissez-le dans le testeur. Cochez Preserve log, collez cette chaîne dans le filtre. Elle ne doit figurer ni dans une ligne XHR / Fetch, ni dans la query, ni dans le corps. Elle ne doit pas non plus apparaître dans une query ou un corps d’analyse. Les ressources statiques, les polices et le fichier de liste peuvent apparaître : que la liste quitte l’origine est attendu. Que le mot de passe testé parte, c’est un échec.

  1. Ouvrez Network, cochez Preserve log, terminez un contrôle, puis trouvez la réponse du fichier de liste et comptez les lignes.
  2. Relancez avec un mot de passe canari et cherchez cette chaîne dans le filtre. Une correspondance sur n’importe quelle requête signifie que le clair a quitté l’onglet.
  3. S’il n’y a pas de correspondance, ouvrez les requêtes d’analyse et confirmez que titres et chemins peuvent apparaître, mais pas le texte entier du champ.

La phrase que cela soutient est étroite : dans cette passe, le mot de passe testé n’a pas quitté l’onglet courant comme champ HTTP observé, et la couverture de la liste égale les lignes que vous avez comptées. Cela ne prouve pas qu’une extension n’a pas lu le champ, ni que le script de la semaine prochaine se comportera pareil. Changez de navigateur ou de version, et il vaut la peine de rechercher le canari à nouveau.

L’entropie et la liste répondent à des questions différentes

Une page de test affiche souvent une note, un nombre de bits, et si la liste a trouvé une correspondance. Les traiter comme un seul score, et vous serez perdu quand les bits ont l’air corrects mais que la liste correspond, ou quand il n’y a pas de correspondance mais que la chaîne est courte. Elles répondent à des questions différentes. Elles ne doivent pas s’annuler.

L’entropie demande : si un attaquant épuise le jeu de caractères, combien de temps cela prend-il en moyenne ? Une formule courante est la longueur multipliée par log2(taille du jeu), puis une décote pour les caractères répétés ou les longues suites du même caractère. Si les seuils sont écrits ≥ 80 bits pour très fort, ≥ 60 pour fort, ≥ 40 pour moyen, et le reste faible, ce sont les cases de cet estimateur. Ce ne sont pas des temps de craquage mesurés en laboratoire. Les horloges hors ligne et en ligne utilisent aussi des cadences différentes — par exemple 1010 essais par seconde hors ligne et 103 en ligne, puis le cas moyen (la moitié de l’espace). Changez la cadence, le temps change. Le mot de passe, non.

La liste demande : cette chaîne est-elle déjà publiquement trop utilisée ? Elle n’emploie pas le nombre de bits. Une correspondance doit rester marquée faible même si elle contient par hasard une majuscule et un symbole. Une absence de six caractères aura une entropie basse, et la longueur seule la poussera vers faible — cela n’a rien à voir avec un corpus de fuites. Un avertissement « plus faible qu’il ne devrait » sous 8 caractères est un avertissement de longueur, pas d’une base de fuites.

Une lecture complète regarde donc au moins trois endroits : la liste a-t-elle correspondé, la chaîne est-elle trop courte, et dans quelle case d’entropie elle tombe. Seulement après ces trois points peut-on dire « à quoi cette chaîne ressemble maintenant ». Cela ne remplace toujours pas un gestionnaire de mots de passe, ni « un mot aléatoire par site ».

S’entraîner à la frontière sur un testeur prêt à l’emploi

Si vous voulez une page qui écrit la frontière à découvert, commencez par le test de force MakePwd. Il s’ouvre sans inscription et sans coffre de mots de passe. La copie produit dit que le mot de passe testé n’est pas envoyé et n’est pas écrit dans les statistiques. La comparaison se fait contre une liste publique de mots fréquents téléchargée dans cet onglet. Ce n’est pas Have I Been Pwned, et ce n’est pas un contrôle de bourrage à l’échelle du web. Une correspondance force la note à faible. Au-delà de 128 caractères, l’implémentation ne fait plus qu’une correspondance exacte et saute les chiffres de fin et le leet.

Entraînez-vous avec une chaîne jetable, pas un mot de passe vivant. Laissez Network ouvert : vous devez voir le fichier de liste et éventuellement des statistiques, pas le texte entier du champ. Quand il faut un nouveau mot de passe, le générateur s’ouvre aussi sans compte. Le mode aléatoire va de 6 à 128 caractères, 16 par défaut, et une chaîne plus courte que 8 reçoit un avertissement de sécurité plus faible. Génération et contrôle se terminent dans le navigateur. Le clair reste par défaut sur cet appareil.

Le but de l’exercice n’est pas de prouver qu’un site « cherche le plus loin ». C’est de pouvoir dire trois phrases à un collègue : j’ai compté les lignes de la liste ; j’ai cherché un canari dans Network ; en cas d’absence, je n’ai écrit que « absent de cette liste ». Sur n’importe quelle autre page qui revendique un « contrôle local de mots de passe faibles », les mêmes étapes tiennent.

Trois points à retenir la prochaine fois

Premier : une correspondance, on change ; une absence n’écarte que la liste courante — ne la lisez pas comme « jamais fuité ». Deuxième : une liste locale courte, le préfixe de hachage à cinq caractères de HIBP, et un corpus hors ligne complet sont trois chemins de données différents, et le sens d’une absence suit le chemin. Troisième : n’annulez pas l’entropie et la liste l’une par l’autre — un mot court peut être absent, un mot long mais courant peut correspondre.

Si la question suivante est de savoir si le clair a quitté cet onglet comme donnée métier, lisez Chiffrer dans le navigateur : comment vérifier que le texte en clair n’a pas quitté l’appareil. Cette note ne fait que transformer « que couvre la liste de mots de passe faibles » en une phrase que vous pouvez écrire.