Credential stuffing sur une billetterie : anatomie d’une vague de connexions suspectes

Quatre-vingt-quatorze pour cent des tentatives de connexion, en l’espace de trois heures, provenaient de moins de quarante adresses IP différentes. C’est ce chiffre, remonté par un simple grep sur les journaux d’accès d’une billetterie culturelle, qui a mis la puce à l’oreille d’un développeur en charge de la maintenance. Le site vendait des places pour des concerts et des spectacles, avec des comptes utilisateurs classiques : email, mot de passe, historique de commandes.

Ce que révélait ce chiffre n’était pas une attaque par force brute classique, où l’on essaie des milliers de mots de passe sur un seul compte. C’était l’inverse : un seul mot de passe (ou une poignée) testé sur des milliers de comptes différents, avec des paires email/mot de passe provenant très probablement d’une fuite de données antérieure, sur un tout autre service. C’est ce qu’on appelle le credential stuffing, ou bourrage d’identifiants.

Pourquoi le credential stuffing diffère du force brute

Le force brute générique cible un compte précis et enchaîne les mots de passe. Le credential stuffing part du principe, statistiquement vérifié, qu’une part significative des internautes réutilise le même couple email/mot de passe sur plusieurs sites. Un attaquant qui récupère une base de données compromise sur un forum de bricolage ou un service de streaming va donc essayer ces mêmes identifiants ailleurs, y compris sur une billetterie qui n’a jamais été piratée elle-même.

Le symptôme observable dans les journaux WordPress est caractéristique : de nombreuses requêtes POST vers wp-login.php, chacune avec un email différent mais un nombre restreint de mots de passe (souvent moins de dix variantes), réparties sur un nombre limité d’adresses IP ou, plus sournois encore, distribuées via un réseau de machines compromises pour brouiller la détection par IP.

Lire les signaux dans les journaux avant qu’il ne soit trop tard

Sur ce site, le premier réflexe a été d’isoler les tentatives échouées sur une fenêtre de temps courte :

grep "POST /wp-login.php" access.log \
  | awk '{print $1}' \
  | sort | uniq -c | sort -rn | head -20

Ce tri par adresse IP a immédiatement montré une concentration anormale. Mais l’indicateur le plus fiable reste le taux d’échec par email unique : sur une billetterie qui gère quelques centaines de connexions légitimes par jour, voir apparaître plusieurs milliers d’emails distincts jamais vus auparavant, chacun tenté une seule fois, est un signal beaucoup plus net qu’un pic de trafic générique.

Le plugin WPS Hide Login ne traite pas ce problème : masquer l’URL de connexion ne fait que retarder un attaquant motivé. La vraie parade se joue à trois niveaux.

Premier niveau : limiter le débit sans pénaliser les clients

La tentation est de bloquer une IP après trois échecs. Sur une billetterie, ce réglage est dangereux : un client qui a oublié son mot de passe et retente plusieurs fois se retrouve bloqué en pleine période de vente. Il faut distinguer le rythme d’un humain de celui d’un script :

• Un throttling progressif (délai croissant entre les tentatives) plutôt qu’un blocage sec.
• Un seuil basé sur le nombre d’emails distincts testés depuis une même IP, pas seulement sur le nombre d’échecs.
• Une alerte automatique dès qu’un seuil anormal est franchi, envoyée à l’équipe technique avant que le pic ne se transforme en incident.

Deuxième niveau : détecter la réutilisation de mots de passe compromis

WordPress permet de vérifier, au moment de l’inscription ou du changement de mot de passe, si celui-ci figure dans une base de fuites connues, via l’API Have I Been Pwned (vérification par préfixe de hachage k-anonymat, sans jamais envoyer le mot de passe en clair). Un simple appel HTTP côté serveur, déclenché sur le hook validate_password_reset ou lors de l’inscription, suffit à refuser un mot de passe déjà exposé publiquement.

Troisième niveau : l’authentification à deux facteurs comme filet de sécurité

Même si un identifiant volé fonctionne, un second facteur (code envoyé par email, application d’authentification) arrête l’attaque net. Sur une billetterie où les comptes stockent parfois des moyens de paiement enregistrés, ce filet n’est pas un luxe.

Sur ce type de site, ne réagissez jamais uniquement sur le nombre de tentatives par IP : les attaques distribuées rendent cet indicateur trompeur. Le nombre d’emails distincts jamais vus, testés en rafale, est bien plus révélateur.

En résumé

Le credential stuffing ne cherche pas une faille dans le code de la billetterie : il exploite une habitude humaine, la réutilisation des mots de passe. La détection passe par une lecture fine des journaux, la parade par un throttling intelligent, une vérification des mots de passe compromis et, en dernier rempart, la double authentification. Sur un site qui traite des paiements, ces trois couches ne sont plus optionnelles.