Mots de passe faibles et force brute responsable (en labo uniquement)
Votre carte de l’application est dressée. Voici la première porte à examiner : celle qui sépare les visiteurs des utilisateurs reconnus. Une authentification mal conçue est l’une des faiblesses les plus coûteuses, car elle ouvre l’accès à tout le reste. Dans cette leçon, vous comprenez comment on évalue la résistance d’un formulaire de connexion face aux mots de passe faibles, et surtout comment on s’en protège.
Rappel légal et éthique
Essayer de nombreux mots de passe sur un compte qui n’est pas le vôtre, sur un service que vous n’avez pas le droit de tester, constitue un accès frauduleux au sens des articles 323-1 à 323-3-1 du Code pénal, même si l’essai échoue. Les exercices de cette leçon se font uniquement sur votre application d’entraînement locale (DVWA, Juice Shop ou laboratoire de la PortSwigger Academy). Les victimes réelles de ce type d’attaque sont des personnes dont les comptes sont détournés : ce savoir sert à les protéger.
Pourquoi les mots de passe faibles posent problème
Le cours sur les fondamentaux de la cybersécurité l’a expliqué côté utilisateur : un mot de passe court, courant ou réutilisé est facile à deviner. Côté application, le problème a deux visages :
- l’application accepte des mots de passe médiocres, sans exigence de longueur ;
- l’application laisse essayer sans limite : rien ne ralentit celui qui teste des milliers de combinaisons.
Quand un auditeur évalue l’authentification, il cherche donc à répondre à quatre questions : quelle politique de mot de passe est imposée ? Que se passe-t-il après plusieurs échecs ? Les messages d’erreur révèlent-ils quelque chose ? Les identifiants par défaut existent-ils encore ?
Trois familles de tentatives
| Technique | Principe | Ce qu’elle révèle côté défense |
|---|---|---|
| Force brute | Essayer systématiquement toutes les combinaisons d’un ensemble de caractères | Absence de limitation et de blocage |
| Attaque par dictionnaire | Essayer des mots de passe très courants issus d’une liste | Politique de mots de passe trop laxiste |
| Bourrage d’identifiants | Réutiliser des couples identifiant/mot de passe issus de fuites d’autres services | Absence de détection d’activité anormale, réutilisation par les utilisateurs |
La force brute pure est rarement efficace contre un mot de passe long. Les deux autres exploitent surtout les habitudes humaines : on choisit des mots de passe prévisibles et on les réutilise.
L’énumération de comptes : un indice discret
Avant même de tester des mots de passe, un testeur observe les réponses de l’application. Comparez ces deux messages :
- « Identifiant inconnu » / « Mot de passe incorrect » : l’application révèle si le compte existe.
- « Identifiant ou mot de passe incorrect » : le message est identique dans les deux cas.
Le premier permet de constituer une liste de comptes valides, ce qui réduit le travail d’un attaquant. D’autres signaux trahissent la même chose : un temps de réponse différent, un code de statut différent, un message différent à l’inscription (« cette adresse est déjà utilisée »). Un constat classique de rapport : « énumération de comptes possible via le message d’erreur de connexion ».
Démarche d’évaluation en laboratoire
Voici, en restant au niveau des principes, comment on évalue un formulaire de connexion dans DVWA (niveau de sécurité bas) :
- Observer le comportement normal : tentez une connexion valide puis une invalide, et lisez les réponses dans l’historique du proxy.
- Comparer les messages pour détecter une énumération.
- Tester la limitation : envoyez volontairement quelques échecs successifs (cinq à dix, pas des milliers) sur un compte de test que vous avez créé. L’application ralentit-elle, bloque-t-elle, ou continue-t-elle comme si de rien n’était ?
- Rejouer la requête de connexion avec le module de rejeu du proxy en changeant le mot de passe, pour mesurer la réaction.
- Utiliser un module d’automatisation avec une toute petite liste de mots de passe d’entraînement (une dizaine de valeurs), pour comprendre le mécanisme. Le but est de constater l’absence de protection, pas de « casser » quoi que ce soit.
Une liste très courte est volontaire : en audit, la preuve d’un défaut de limitation se fait avec quelques tentatives, pas avec un volume massif qui risquerait de verrouiller des comptes ou de saturer le service.
Ce que l’on constate dans l’application d’entraînement
Au niveau de sécurité le plus bas de DVWA, le formulaire de connexion à tester ne limite pas les essais et répond de manière identique à chaque échec : aucun délai, aucun blocage. Aux niveaux supérieurs, vous verrez apparaître un petit délai, puis un jeton, puis un verrouillage temporaire. Comparer les niveaux est très instructif : vous voyez, concrètement, ce que chaque contre-mesure apporte.
Les défenses à recommander
Un constat de test n’a de valeur que s’il s’accompagne d’une solution. Voici les mesures courantes :
- Limiter le débit : ralentir ou bloquer temporairement après plusieurs échecs, par compte et par source.
- Éviter le verrouillage permanent : il permettrait à un attaquant de bloquer les comptes de tout le monde. Préférez un verrouillage temporaire croissant.
- Messages d’erreur uniformes à la connexion, à l’inscription et à la récupération de compte.
- Politique de mots de passe moderne : privilégier la longueur, refuser les mots de passe connus comme compromis ou trop courants, plutôt qu’imposer des règles de composition compliquées. Les recommandations du NIST (nist.gov) et de l’ANSSI (cyber.gouv.fr) vont dans ce sens.
- Stocker les mots de passe correctement : hachage lent et salé, jamais en clair (vu dans le cours sur la cryptographie).
- Supprimer les comptes par défaut et imposer un changement au premier usage.
- Authentification multifacteur, que nous verrons à la fin de ce chapitre.
- Détection et alertes sur les pics d’échecs de connexion.
Astuce de rédaction
Dans le carnet, notez le nombre de tentatives que vous avez faites et le comportement observé (« aucun délai après 10 échecs »). Cela rend la preuve claire et vérifiable, et montre que vous avez agi avec mesure.
À vous de jouer
Dans votre application d’entraînement locale, évaluez la page de connexion.
- Créez un compte de test dont le mot de passe est volontairement faible, par exemple une valeur très courte que vous inventez pour le labo.
- Comparez les messages obtenus pour un identifiant inexistant et pour un identifiant existant avec un mauvais mot de passe.
- Effectuez dix échecs de connexion successifs et notez si un délai, un blocage ou une alerte apparaît.
- Rédigez deux constats dans le carnet (un par observation), avec gravité estimée et correction suggérée.
- Remontez le niveau de sécurité de l’application, si elle le permet, et refaites l’exercice : qu’est-ce qui change ?
Voir une solution
Constat 1 : « Énumération de comptes. Message différent pour identifiant inconnu et mot de passe erroné. Gravité faible à moyenne. Correction : message unique et neutre. » Constat 2 : « Absence de limitation des tentatives. Dix échecs consécutifs sans délai ni blocage. Gravité moyenne à élevée selon le contexte. Correction : ralentissement progressif, verrouillage temporaire, détection. » Aux niveaux de sécurité supérieurs de DVWA, vous observerez typiquement un délai ou un jeton supplémentaire : preuve que la contre-mesure fonctionne.
À retenir
- Tester des mots de passe sur un compte ou un service que vous n’avez pas le droit de tester est illégal : seul le labo est un terrain d’exercice.
- On évalue la politique de mots de passe, la limitation des essais, les messages d’erreur et les comptes par défaut.
- Un message d’erreur différent selon que le compte existe permet l’énumération de comptes.
- La preuve d’un défaut de limitation se fait avec quelques tentatives, pas avec un volume massif.
- Défense : limiter le débit, verrouillage temporaire, messages uniformes, longueur, hachage salé, MFA, détection.
Un utilisateur authentifié reçoit ensuite un « laissez-passer » : le cookie de session. La leçon suivante examine comment le protéger.