Attaques par dictionnaire et force brute, menées de façon responsable en labo
Deviner un mot de passe, une tentative après l'autre, est la plus ancienne des techniques d'attaque. Elle reste redoutablement efficace, précisément parce que le facteur humain — mots de passe faibles, réutilisés, prévisibles — ne disparaît jamais complètement. Cette leçon décrit le principe de ces attaques et, surtout, les protections qu'un système doit mettre en œuvre.
Rappel impératif. Toute tentative de connexion répétée contre un système, un formulaire de connexion ou un service, sans autorisation écrite et périmètre défini, est une infraction (articles 323-1 à 323-3-1 du Code pénal) et peut en outre provoquer un blocage de comptes légitimes ou une interruption de service. Les exemples de cette leçon se pratiquent uniquement sur les comptes de test de votre labo isolé, jamais sur un compte ou un service réel, y compris le vôtre sur un service en ligne grand public.
Deux familles d'attaques sur le mot de passe lui-même
- L'attaque par dictionnaire : on essaie une liste de mots de passe probables (mots courants, variantes, mots de passe déjà vus dans des fuites publiques, informations liées à la cible comme un prénom ou une date). Elle est efficace car de nombreux utilisateurs choisissent des mots de passe prévisibles ou réutilisent un mot de passe compromis ailleurs.
- La force brute : on essaie systématiquement toutes les combinaisons possibles selon un jeu de caractères et une longueur donnés. Elle finit toujours par trouver le mot de passe, mais son coût augmente de façon spectaculaire avec la longueur : chaque caractère supplémentaire multiplie le nombre de combinaisons possibles par le nombre de caractères du jeu utilisé. C'est exactement ce qui explique, techniquement, pourquoi la longueur protège plus efficacement qu'une complexité artificielle, comme vous l'avez appris dans le premier cours du parcours.
Où ces attaques s'appliquent-elles ?
Deux contextes très différents, qui appellent des protections différentes :
| Contexte | Particularité |
|---|---|
| Attaque hors ligne, sur des hachages déjà obtenus | Aucune limite de débit imposée par un serveur distant : seule la puissance de calcul de l'attaquant limite la vitesse. C'est ici que le salage et le facteur de coût (vus à la leçon précédente) jouent un rôle décisif. |
| Attaque en ligne, contre un formulaire de connexion | Chaque tentative passe par le réseau et peut être ralentie, limitée ou détectée par le service ciblé. C'est ici que les protections applicatives (verrouillage, délai, détection) sont essentielles. |
Démonstration de principe en labo : l'attaque en ligne
Sur une application d'entraînement de votre labo (par exemple une application volontairement vulnérable comme DVWA), vous pouvez observer le comportement d'un formulaire de connexion face à des tentatives répétées, avec des comptes de test que vous avez vous-même créés. Le principe, décrit ici sans fournir d'outil ni de commande d'attaque prêts à l'emploi : on envoie successivement des couples nom d'utilisateur / mot de passe issus d'une liste, vers le formulaire, et on observe les réponses pour repérer celle qui diffère (indiquant un succès), ou les signes que le service commence à limiter ou bloquer les tentatives.
Ce qu'il faut observer et noter dans votre carnet, plutôt que l'outil utilisé :
- Le formulaire limite-t-il le nombre de tentatives par minute, par compte, par adresse ?
- Au bout de combien d'essais un verrouillage ou un ralentissement apparaît-il ?
- Le message d'erreur est-il identique pour « utilisateur inconnu » et « mot de passe incorrect » ? S'ils diffèrent, un attaquant peut déjà déduire quels noms d'utilisateur existent, avant même de deviner un mot de passe — une faille souvent négligée.
- Une authentification à deux facteurs, si elle est activée, bloque-t-elle réellement l'accès même avec le bon mot de passe ?
Les protections applicatives contre les attaques en ligne
| Protection | Principe | Limite à connaître |
|---|---|---|
| Verrouillage de compte | Bloque le compte après N échecs | Peut être détourné pour bloquer volontairement les comptes d'autrui (déni de service ciblé) |
| Ralentissement progressif | Augmente le délai entre les tentatives après des échecs | Doit être calibré pour ne pas gêner l'utilisateur légitime qui se trompe une fois |
| Limitation par adresse réseau | Limite le nombre de tentatives depuis une même origine | Un attaquant déterminé peut utiliser de nombreuses origines différentes |
| Message d'erreur générique | Ne révèle pas si c'est le nom d'utilisateur ou le mot de passe qui est faux | Doit être cohérent avec le temps de réponse, sinon l'attaquant déduit l'information autrement |
| Authentification à deux facteurs | Un mot de passe deviné ne suffit plus | Protection la plus efficace contre ce type d'attaque, voir le premier cours du parcours |
| Détection et alerte | Signale à l'équipe de sécurité une vague de tentatives suspectes | Nécessite une supervision active pour être utile |
Aucune de ces mesures n'est infaillible seule ; c'est leur combinaison qui rend une attaque par force brute réellement difficile à mener avec succès.
Le cas particulier du « credential stuffing »
Une variante très efficace mérite d'être connue : plutôt que de deviner un mot de passe au hasard, un attaquant réutilise des couples identifiant/mot de passe issus de fuites publiques d'autres services, en pariant que des utilisateurs réutilisent les mêmes mots de passe ailleurs. Cette technique ne « devine » rien : elle exploite directement la réutilisation des mots de passe par les utilisateurs. C'est l'un des arguments les plus forts en faveur des gestionnaires de mots de passe et de l'authentification à deux facteurs, vus dans le premier cours du parcours : même si un mot de passe fuite ailleurs, le compte reste protégé.
Pourquoi attaquer soi-même son propre système en labo a du sens
Tester la résistance d'un formulaire de connexion sur votre propre labo, avec des comptes de test, permet de répondre concrètement à une question que l'analyse théorique ne peut pas trancher seule : « en pratique, combien de temps faudrait-il pour deviner un mot de passe faible sur ce système précis, compte tenu de ses protections réelles ? ». C'est exactement la différence entre lire une recommandation générale et la vérifier dans un contexte donné, ce qui est la raison d'être d'un test d'intrusion.
À vous de jouer : auditer un formulaire de votre labo
Sur une application d'entraînement légale installée dans votre labo, avec un compte de test que vous avez créé vous-même, observez le comportement du formulaire de connexion : combien de tentatives sont possibles avant un ralentissement ou un blocage ? Les messages d'erreur distinguent-ils un nom d'utilisateur inconnu d'un mot de passe incorrect ? Documentez vos observations dans un tableau, puis rédigez une recommandation priorisée (reprenez la grille du chapitre 3) pour l'application testée.
Voir une solution
Exemple d'observation pour une application volontairement vulnérable mal configurée : aucun verrouillage après de nombreux échecs, message d'erreur différent selon que le nom d'utilisateur existe ou non. Recommandation priorisée : exposition élevée (formulaire public), facilité d'exploitation élevée (aucune protection), donc priorité haute : mettre en place un verrouillage ou un ralentissement progressif, unifier les messages d'erreur, et recommander l'authentification à deux facteurs comme protection complémentaire la plus efficace.
Astuce. Lors d'une mission réelle, prévenez toujours le client avant de tester un formulaire de connexion en conditions répétées : vous pourriez déclencher des alertes de sécurité, verrouiller de vrais comptes, ou être vous-même bloqué par une protection automatique, ce qui doit être anticipé dans les règles d'engagement.
À retenir
- L'attaque par dictionnaire exploite la prévisibilité des mots de passe ; la force brute teste systématiquement toutes les combinaisons, d'où l'importance de la longueur.
- Une attaque hors ligne (sur des hachages) n'a pas de limite de débit imposée par un serveur ; une attaque en ligne (sur un formulaire) peut être ralentie, limitée et détectée.
- Verrouillage, ralentissement, limitation par origine, messages d'erreur génériques et authentification à deux facteurs se combinent pour une protection efficace.
- Le credential stuffing réutilise des fuites d'autres services : la réutilisation de mots de passe en est la cause directe.
- Ces tests ne se pratiquent que sur des comptes de test, dans un périmètre autorisé, jamais sur un service réel ou un compte qui ne vous appartient pas.
La prochaine leçon aborde une autre voie d'attaque sur les identifiants, qui ne nécessite même pas de deviner un mot de passe : le pass-the-hash et les attaques de rejeu.