Hashcat pour casser hors ligne des empreintes de mots de passe

hashcat teste des millions de candidats de mots de passe contre des empreintes déjà en sa possession, sans jamais parler au service d’origine. C’est l’outil de référence pour mesurer ce que vaut vraiment une politique de mots de passe, et l’outil qu’un attaquant lance après une fuite de base.

→ Lire l’explication complète de la marmotte

Le cassage hors ligne : attaquer une empreinte sans toucher au serveur

Un mot de passe stocké correctement ne l’est jamais en clair : le service garde une empreinte, le résultat d’une fonction de hachage appliquée au mot de passe. Vérifier une connexion revient à rehacher la saisie et à comparer. Le cassage hors ligne commence quand cette empreinte fuit : dump de base, sauvegarde mal protégée, extraction de SAM ou NTDS.dit sur un contrôleur de domaine. L’attaquant détient alors la cible et n’a plus besoin du serveur.

C’est ce qui rend l’exercice redoutable. En ligne, chaque tentative passe par le service : verrouillage de compte après N échecs, limitation de débit, alerte dans les journaux, blocage d’adresse. Hors ligne, rien de tout ça. On teste des candidats sur son propre matériel, aussi vite que la fonction de hachage le permet, et la victime ne voit strictement rien. Le seul événement observable a eu lieu avant, au moment du vol de l’empreinte. Après, c’est le silence.

Pour comprendre ce que garantit une empreinte et ce qu’elle ne garantit pas, voir les propriétés des condensés cryptographiques et la page sur la transformation des mots de passe en condensats.

Le GPU, et pourquoi la fonction de hachage décide de tout

hashcat doit sa réputation au processeur graphique. Un GPU (Graphics Processing Unit) aligne des milliers d’unités de calcul qui exécutent la même opération en parallèle sur des données différentes : exactement ce qu’est le test de masse de candidats. Là où un processeur central déroule quelques dizaines de hachages en parallèle, une carte en traite plusieurs ordres de grandeur de plus. C’est pour ça qu’on choisit sa carte graphique sur la quantité d’unités de calcul et la bande passante mémoire, pas sur le nombre d’images par seconde dans le dernier jeu à la mode.

Mais le GPU ne décide de rien tout seul. La fonction de hachage, elle, décide de tout.

Une fonction rapide (MD5, SHA-1, ou NTLM, le condensat NT utilisé par Windows) a été conçue pour l’intégrité ou la vitesse, pas pour ralentir une attaque. Elle se calcule en une poignée d’opérations, donc elle se teste à une cadence vertigineuse : une base de condensats NTLM volée sur un annuaire Active Directory tombe à une vitesse qui transforme une politique « 8 caractères, une majuscule, un chiffre » en décoration. Le détail du protocole et de ses faiblesses est traité dans la page NTLM.

Une fonction lente et volontairement coûteuse (bcrypt, scrypt, Argon2) inverse le rapport de force. Elle intègre un facteur de coût réglable : on augmente le nombre d’itérations, et pour scrypt ou Argon2 la quantité de mémoire exigée par calcul. Résultat, la cadence de test chute de plusieurs ordres de grandeur par rapport à MD5. Argon2 et scrypt ajoutent la dureté mémoire : le GPU, riche en unités de calcul mais avare en mémoire rapide par unité, perd une large part de son avantage parallèle. Le compromis central tient là : une fonction rapide coûte une fraction de milliseconde au serveur à chaque connexion légitime, et offre à l’attaquant un débit de cassage colossal ; une fonction lente coûte au serveur le même facteur de ralentissement, et l’impose à l’attaquant à chaque candidat. On paie en latence de connexion ce qu’on gagne en résistance hors ligne. Pour une fonction d’authentification, ce prix se paie sans discuter.

Le sel change une autre chose. Un sel est une valeur aléatoire unique, stockée à côté de l’empreinte et mélangée au mot de passe avant hachage. Sans sel, deux utilisateurs avec le même mot de passe ont la même empreinte, et un attaquant précalcule une immense table (type « rainbow table ») valable pour toutes les victimes à la fois. Avec un sel unique par compte, ce précalcul s’effondre : chaque empreinte doit être attaquée séparément, le travail est multiplié par le nombre de comptes. Le sel n’est pas secret et ne ralentit pas un calcul individuel ; il interdit la mutualisation. Le poivre va plus loin : c’est un secret global, le même pour tous les comptes, mélangé lui aussi au mot de passe mais stocké hors de la base (idéalement dans un module matériel). Tant que le poivre, long et aléatoire, ne fuit pas avec la base, les empreintes volées sont hors de portée d’un cassage hors ligne, puisqu’il manque une entrée au calcul.

Modes d’attaque : dictionnaire, règles, masque, combinaison

hashcat ne devine pas : il génère des candidats selon une stratégie choisie, les hache, compare. Quatre familles couvrent l’essentiel.

Le mode dictionnaire teste chaque ligne d’un fichier de mots de passe connus (fuites publiques, listes thématiques). C’est le plus rentable, parce que les humains réutilisent et recyclent. Le mode dictionnaire avec règles applique à chaque mot une série de transformations (majuscule initiale, ajout de chiffres en fin, substitutions de caractères du style « a » en « @ ») : il modélise exactement la créativité prévisible imposée par les politiques de complexité. Le mode masque est une force brute guidée : on décrit la forme du mot de passe par classes de caractères (?l minuscule, ?u majuscule, ?d chiffre, ?s symbole, ?a tout), ce qui restreint l’espace à explorer à ce qui est plausible. Le mode combinaison concatène les mots de deux dictionnaires, pour reconstituer les phrases de passe faites de mots accolés.

Le schéma suivant montre comment l’opérateur choisit son mode selon ce qu’il sait de la cible.

La logique à lire : on part toujours du moins coûteux (dictionnaire) vers le plus coûteux (masque exhaustif), et la fonction de hachage détermine jusqu’où on peut pousser. Sur une fonction lente, le masque long devient inenvisageable, et seule la faiblesse humaine du dictionnaire reste exploitable.

Éditeur, licence, et quand on le sort

hashcat est développé par Jens Steube et un noyau de contributeurs, distribué en logiciel libre sous licence MIT. Il fonctionne sur les cartes graphiques AMD et NVIDIA via leurs piles de calcul, ainsi que sur processeur, et tourne aussi bien sous Linux que sous Windows. Il est préinstallé dans les distributions d’audit, voir Kali Linux.

On le sort dans deux situations. En audit défensif, pour mesurer la robustesse réelle du parc de mots de passe de sa propre organisation, avec accord écrit : on extrait les empreintes dans un périmètre maîtrisé et on regarde combien tombent, à quelle vitesse, et avec quelles stratégies. En test d’intrusion, après avoir mis la main sur une base d’empreintes, pour démontrer l’impact d’une fuite. Dans les deux cas, hashcat ne produit pas de l’exploit, il produit un verdict sur la politique en place.

Ce que hashcat montre et ce qu’il ne montre pas

hashcat montre une chose précise : combien de mots de passe de la liste fournie correspondent à des candidats générables, et à quel coût. C’est une mesure directe de robustesse. Il ne montre pas si un mot de passe non cassé est fort : il peut simplement être absent des dictionnaires et hors de portée du masque testé dans le temps imparti. Un condensat non cassé n’est pas une preuve de solidité, juste l’absence de preuve de faiblesse. Il ne dit rien non plus de la façon dont l’empreinte a fuité, ni de ce qui a été fait du compte après : ça, c’est le travail des journaux côté serveur, qu’hashcat ne touche jamais.

Côté défense, l’enseignement est brutal et chiffrable. Un audit mesure le pourcentage de comptes cassés en un temps donné, repère la réutilisation du même mot de passe sur plusieurs comptes à privilèges, identifie les motifs récurrents (saison plus année, nom de l’entreprise suffixé) que la politique de complexité n’empêche pas. Il tranche aussi la question de la fonction de hachage : si une base NTLM ou un stockage en SHA-1 non salé tombe en un temps dérisoire, la conclusion n’est pas « imposer des mots de passe plus longs », c’est « migrer vers une fonction lente et salée ». Les règles de dérivation et de stockage sont développées dans l’authentification des personnes et des services.

Exemple : trois attaques commentées sur une même base

L’option -m fixe l’algorithme de l’empreinte, -a le mode d’attaque. Voici trois lancements successifs sur un fichier de condensats NTLM (-m 1000), du plus rentable au plus coûteux.

# Attaque par dictionnaire (-a 0) : on teste des mots de passe connus
hashcat -m 1000 -a 0 empreintes.txt dictionnaire.txt

# Dictionnaire + règles (-r) : on applique des transformations à chaque mot
hashcat -m 1000 -a 0 -r rules/best64.rule empreintes.txt dictionnaire.txt

# Masque (-a 3) : force brute guidée sur 8 caractères (majuscule, 5 minuscules, 2 chiffres)
hashcat -m 1000 -a 3 empreintes.txt ?u?l?l?l?l?l?d?d

Le premier lancement épuise la réutilisation pure. Le deuxième capture tout ce que les utilisateurs bricolent par-dessus un mot connu, et c’est souvent là que la moisson double. Le troisième n’est raisonnable que parce que la cible est NTLM, une fonction rapide : le même masque contre du bcrypt ne finirait pas avant longtemps. Changer -m 1000 en -m 3200 (bcrypt) avec le même matériel suffit à faire comprendre, sans un mot de théorie, pourquoi le choix de la fonction de hachage est la seule décision qui compte vraiment.

Détecter le vol des empreintes en amont, pas le cassage

hashcat tourne chez l’attaquant, hors ligne, sur son matériel : il n’émet aucun paquet vers la victime, aucune règle réseau ne l’arrêtera et aucun capteur ne le verra. Vouloir détecter hashcat lui-même est une impasse. La défense se joue entièrement en amont, sur le vol de l’empreinte, le seul moment où l’attaque laisse une trace.

Ce qu’il faut lire : la seule flèche détectable part vers les journaux, en amont ; une fois l’empreinte copiée, la branche hors ligne est invisible. On surveille donc les accès aux magasins d’empreintes (extraction de NTDS.dit sur un contrôleur, copie de ruches SAM, requêtes anormales sur les tables d’authentification, usage d’outils d’extraction de secrets), on chiffre les sauvegardes, on cloisonne les comptes à privilèges capables de lire ces magasins. Et parce que le cassage ne se détecte pas, on réduit son gain : fonction lente et salée pour que la base volée vaille le moins possible, rotation des mots de passe compromis, interdiction de la réutilisation inter-comptes. La supervision consiste à savoir qu’une base a fuité, pas à espérer surprendre l’attaquant en plein calcul.

Limites et cadre légal

hashcat ne contourne aucune fonction de hachage : si l’algorithme est lent et salé, si le poivre n’a pas fuité, si les mots de passe sont de vraies phrases longues et aléatoires, l’outil rend un verdict d’échec, qui est le bon résultat pour le défenseur. Sa performance dépend entièrement du matériel : donner des cadences absolues n’a pas de sens, seuls comptent les ordres de grandeur comparés entre fonctions rapides et lentes. John the Ripper couvre le même usage avec une mécanique voisine, historiquement plus à l’aise sur certains formats exotiques et sur processeur ; les deux se complètent plus qu’ils ne se concurrencent.

Le cadre légal ne tolère aucune zone grise. On ne casse que des empreintes qu’on a le droit de tester : son propre parc, ou un périmètre explicitement autorisé par un mandat écrit précisant les comptes concernés. En France, accéder ou se maintenir frauduleusement dans un système de traitement automatisé de données, ou porter atteinte à son fonctionnement, relève des articles 323-1 et suivants du code pénal, avec des peines d’emprisonnement et d’amende. Détenir hashcat pour auditer, se former ou faire de la recherche est licite : l’article 323-3-1 ne vise que la détention sans motif légitime d’outils conçus pour commettre ces infractions. S’en servir sur des empreintes qu’on n’est pas autorisé à tester ne l’est pas, et l’absence de trace côté victime ne vaut pas absence d’infraction. Un audit interne manipule par ailleurs les mots de passe réels des salariés : l’accord écrit fixe aussi qui voit les résultats, ce qui est conservé et pendant combien de temps.

🐝 Ce qui arrive si on s’en passe

Renoncer à l’audit hors ligne, c’est ignorer la seule mesure directe de ce que vaut une politique de mots de passe. On continue d’afficher une règle de complexité en croyant qu’elle protège, alors qu’un attaquant muni de la base d’empreintes la contourne par dictionnaire et règles en un temps qui ne se mesure pas en années. Sans ce verdict, on ne sait pas qu’une fonction rapide non salée transforme une fuite en effondrement immédiat, ni que des comptes à privilèges partagent le même mot de passe recyclé. La décision de migrer vers une fonction lente et salée, d’ajouter un poivre ou d’interdire la réutilisation ne se prend jamais, faute de preuve chiffrée. La faiblesse reste théorique jusqu’au jour où quelqu’un d’autre la mesure à la place du défenseur.

🦫 Explication de la marmotte 🍫

Un site ne garde jamais le mot de passe en clair. Il garde une empreinte : un calcul qui transforme le mot de passe en une suite de caractères, impossible à remonter à l’envers. Pour vérifier une connexion, le site refait le calcul sur ce qui est tapé et compare les empreintes.

Quand quelqu’un vole la liste de ces empreintes, il peut travailler tranquillement sur son propre ordinateur, sans jamais contacter le site. Il fabrique des mots de passe possibles, les passe dans le même calcul, et regarde si une empreinte obtenue correspond à une empreinte volée. Si oui, il a trouvé le mot de passe. C’est ce que fait hashcat, en utilisant la carte graphique, capable de faire un très grand nombre de ces calculs en même temps.

Tout dépend du calcul choisi par le site. S’il est rapide, l’attaquant teste énormément de mots de passe par seconde et gagne vite. S’il est lent et gourmand en mémoire, chaque test prend tellement de temps que l’attaque devient trop longue. Ajouter une valeur aléatoire propre à chaque compte, le sel, empêche de deviner plusieurs comptes d’un coup.

Si le mot de passe est long et imprévisible, hashcat échoue, et c’est le bon résultat. L’outil sert surtout à vérifier, avec autorisation, si les mots de passe d’une organisation tiendraient le choc. On ne peut pas repérer l’attaquant qui calcule chez lui : on surveille le vol de la liste, en amont, car c’est le seul moment visible.

Pages voisines

La citent

Hashcat pour casser hors ligne des empreintes de mots de passe

Elle cite

: les deux pages se citent l’une l’autre.

Hashcat pour casser hors ligne des empreintes de mots de passe

Hashcat pour casser hors ligne des empreintes de mots de passe

Le cassage hors ligne : attaquer une empreinte sans toucher au serveur

Le GPU, et pourquoi la fonction de hachage décide de tout

Modes d’attaque : dictionnaire, règles, masque, combinaison

Éditeur, licence, et quand on le sort

Ce que hashcat montre et ce qu’il ne montre pas

Exemple : trois attaques commentées sur une même base

Détecter le vol des empreintes en amont, pas le cassage

Limites et cadre légal

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines