Skip to content

La combinaison dictionnaire et règles qui casse vraiment les mots de passe

rockyou.txt est une ligne de départ, pas une stratégie. Comment combiner dictionnaires soignés, règles, masques et listes ciblées, et quand chacun gaspille du temps GPU.

Publié le 5 min de lecture

Tout le monde commence avec rockyou.txt et la plupart n'en sortent jamais. C'est très bien. Il cassera les mots de passe vraiment catastrophiques dans les premières minutes de n'importe quelle mission, et pour beaucoup de cibles peu rigoureuses, c'est tout l'engagement. Mais rockyou est une fuite de 2009 d'environ 14 millions d'entrées, et si en 2026 vous ne lancez encore que ça contre un hash, vous laissez la majorité des mots de passe cassables sur la table.

La liste est la matière première. Les règles sont ce qui la transforme en couverture.

Les règles multiplient, et c'est tout l'intérêt

Un dictionnaire est statique. Le mot de base password y figure une fois. Mais les vrais mots de passe sont des mots de base avec des mutations : une majuscule, une année, un point d'exclamation à la fin, un a remplacé par @. Les règles appliquent ces transformations à la volée, si bien qu'un mot de dictionnaire devient des centaines de candidats sans que vous ayez à les stocker.

hashcat -m 0 -a 0 hashes.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

best64 est le choix par défaut raisonnable. Petit, rapide, il attrape les classiques. Quand il revient bredouille et que vous avez du débit en réserve, montez d'un cran vers quelque chose de plus lourd. OneRuleToRuleThemAll est celui que la plupart des gens dégainent, et dive.rule si vous voulez être exhaustif et avez du temps à brûler. Le coût est réel : les règles multiplient votre espace de clés par le nombre de règles du fichier, donc un fichier de 50 000 règles transforme 14 millions de mots en 700 milliards de candidats. Sur un hash rapide comme MD5 ou NTLM, c'est très bien. Sur tout ce qui est salé et lent, c'est une chimère.

Voilà l'arbitrage que personne n'énonce clairement : les règles sont gratuites sur les hash rapides et ruineuses sur les lents.

Arrêtez d'utiliser rockyou sur du bcrypt

C'est l'erreur que je vois le plus. Quelqu'un identifie un hash bcrypt, lui balance rockyou plus OneRule et s'en va en attendant des résultats. Le bcrypt à facteur de coût 10 vous donne peut-être quelques milliers d'essais par seconde par GPU. Faites le calcul. 14 millions de mots multipliés par un jeu de 50 000 règles à quelques milliers par seconde, cela se mesure en années, pas en heures.

Pour les hash lents, la stratégie s'inverse. Vous voulez une petite liste de qualité, ciblée, un jeu de règles léger, et vous acceptez de n'obtenir que les mots de passe faibles. La raison pour laquelle les hash rapides tombent et les lents non est la même raison pour laquelle votre stratégie de dictionnaire doit changer avec l'algorithme.

Les listes soignées battent les listes plus grosses

Plus gros n'est pas meilleur au-delà d'un certain point. Un dictionnaire de 100 Go rempli de déchets aléatoires aspirés sur le web passe l'essentiel de son temps sur des candidats qu'aucun humain n'a jamais choisis. Les listes qui valent la peine d'être conservées sont les listes soignées, bâties à partir de vrais mots de passe cassés : les collections weakpass, les founds de hashmob, hashesorg. Elles sont ordonnées par fréquence, donc les correspondances probables arrivent en premier et vous pouvez vous arrêter tôt une fois ce qu'il vous faut obtenu.

Gardez rockyou pour les victoires instantanées. Gardez une grande liste soignée pour la seconde passe. Cela couvre l'essentiel de ce que les attaques par dictionnaire vous donneront jamais.

Les masques pour ce qui est structuré

Quand le travail au dictionnaire s'épuise, les mots de passe restants tendent à être structurés plutôt qu'aléatoires. Huit caractères, commence par une majuscule, finit par deux chiffres. C'est une attaque par masque, pas par dictionnaire :

hashcat -m 0 -a 3 hashes.txt ?u?l?l?l?l?l?d?d

Les masques sont de la force brute avec un motif, et ils ne paient que lorsque vous disposez de renseignements sur la politique de mots de passe. Si le domaine impose exactement huit caractères avec une majuscule et un chiffre, l'espace de clés est assez petit pour être épuisé. Les attaques hybrides (-a 6 et -a 7) greffent un masque sur un dictionnaire, ce qui attrape le motif dictionnaire + 2024 que les règles pures ratent parfois.

Construisez une liste ciblée avant d'abandonner

Le geste à plus forte valeur sur une mission réelle, c'est une liste personnalisée bâtie à partir de la cible. Nom de l'entreprise, noms des produits, équipes sportives locales, la saison et l'année en cours. Les gens sont prévisibles : Spring2026!, Acme2026, Houston2024. Aspirez le site de l'entreprise avec un outil comme cewl, mélangez le tout avec des mois et des années, et lancez cette petite liste en premier. Elle casse les mots de passe qu'aucun dictionnaire générique ne contiendra jamais, parce qu'ils n'ont jamais figuré dans la moindre fuite.

Réutilisez votre travail

Chaque mot de passe que vous cassez alimente la cible suivante. Hashcat écrit ses trouvailles dans un potfile, et --loopback réinjecte les mots de passe cassés comme nouveaux mots de dictionnaire, attrapant souvent des variations à l'échelle d'une organisation où tout le monde a convergé vers le même mot de base. Gardez votre potfile. Gardez vos listes personnalisées par client. La deuxième mission chez la même entreprise est toujours plus rapide, parce que la moitié des mots de passe sont réutilisés depuis la première.

Rien de tout cela ne compte si vous n'avez rien cassé parce que vous vous êtes trompé d'algorithme. Trouvez d'abord le mode, confirmez-le contre un mot de passe connu, puis seulement souciez-vous de la liste à lancer.

Articles liés

Comparaison pratique de hashcat et John the Ripper — forces GPU et CPU, détection automatique, modes -m, formats jumbo, dictionnaires et règles — avec des commandes d'exemple.
Pourquoi bcrypt fait chuter le débit de cassage de milliards à quelques milliers par seconde : facteur de coût, key schedule hostile au GPU, et 72 octets.
Hashcat ne devine rien. Voici comment choisir le bon mode -m, distinguer les hash qui se ressemblent et lire les erreurs qui trahissent un mauvais choix.