Le credential stuffing consiste à rejouer contre votre connexion des paires e-mail et mot de passe fuitées d'autres sites. Les gens réutilisent leurs mots de passe, donc une petite part de n'importe quelle liste fuitée fonctionne presque partout. L'attaquant n'a pas besoin de casser votre système ; il lui faut du volume, et un formulaire de connexion qui répond vite.
À quoi cela ressemble dans vos logs
- Un taux d'échec qui bondit. Les connexions normales réussissent le plus souvent. Une vague de stuffing échoue dix-neuf fois sur vingt.
- Beaucoup de comptes, peu de tentatives chacun. Contrairement à la force brute, chaque compte est essayé une ou deux fois, donc les blocages par compte ne se déclenchent jamais.
- Beaucoup d'adresses. Les tentatives passent par des pools de proxies résidentiels, donc bloquer les principales IP n'y change presque rien.
- Des connexions sans page. L'endpoint de connexion est appelé directement, par des clients qui n'ont jamais chargé la page de connexion.
- Un timing de machine. Des requêtes à cadence régulière, aux heures où vos clients dorment.
Pourquoi les défenses habituelles ne suffisent pas
Les rate limits par IP sont contournés par des pools de proxies aux milliers de sorties. Les blocages de compte pénalisent vos clients plus que l'attaquant, et peuvent devenir un moyen de bloquer des gens volontairement. Les CAPTCHA sont résolus par des services payants pour une fraction de centime. Chacun ajoute de la friction pour les vraies personnes et un petit coût pour les bots.
Juger le client, pas seulement la requête
Un outil de stuffing peut changer d'IP et de User-Agent à chaque requête. Ce qu'il a du mal à falsifier, c'est un navigateur entier et cohérent qui a chargé votre page, exécuté votre script et se comporte comme une personne tout au long de la session :
- un token signé issu de la page, absent ou partagé entre de nombreuses sessions ;
- des indicateurs d'automatisation et des empreintes de navigateur qui ne concordent pas ;
- un appareil ou un token qui essaie de nombreux comptes différents ;
- des tentatives qui continuent malgré les erreurs, ce que les gens ne font pas.
Où placer la vérification
Interrogez avant de vérifier le mot de passe, pour qu'un bot n'apprenne jamais si une paire fonctionne :
- bot high : répondez comme si le mot de passe était faux. L'outil n'apprend rien, et votre client n'est jamais concerné.
- bot : demandez un second facteur ou un code envoyé par e-mail avant de laisser entrer la session.
- tous les autres : la connexion normale.
Répondre à un bot avec le même « mot de passe incorrect » qu'une personne verrait compte : une page de blocage distincte indique à l'attaquant de changer de tactique.
Après la connexion
Dites à votre vérification anti-bots ce qui s'est passé ensuite. Une connexion qui passe plus tard une vraie commande, ou un chargeback qui prouve le contraire, est une preuve qu'aucun en-tête de requête ne peut falsifier, et elle affine la décision suivante sur le même visiteur.