Arrêter le credential stuffing en périphérie
Comment tracio.ai identifie les tentatives de connexion automatisées avant qu'elles n'atteignent votre système d'authentification — en combinant empreintes d'appareils, contrôles de vélocité et signaux comportementaux.
Le credential stuffing
(bourrage d'identifiants) utilise des outils automatisés pour tester des combinaisons volées de nom d'utilisateur et de mot de passe contre les pages de connexion. Les attaques sont massives — un seul opérateur peut tester des millions d'identifiants par jour sur des centaines de sites cibles. Les défenses traditionnelles comme la limitation de débit et les CAPTCHA sont insuffisantes car les attaquants répartissent leurs requêtes sur des milliers d'adresses IP et utilisent des services de résolution de CAPTCHA. Voici comment nous arrêtons le credential stuffing en périphérie, avant que les requêtes n'atteignent votre système d'authentification.
La surface d'attaque
Une opération typique de credential stuffing utilise une liste d'identifiants volés (disponibles sur les places de marché du dark web pour aussi peu que 10 dollars le million d'enregistrements), un outil d'automatisation (généralement un script personnalisé ou un outil comme OpenBullet) et un pool d'IP de proxy (des proxies résidentiels qui tournent à chaque requête pour échapper à la limitation de débit basée sur l'IP).
L'attaquant configure son outil pour envoyer des requêtes de connexion à un rythme contrôlé — assez lent pour éviter de déclencher les limites de débit simples, mais assez rapide pour tester des milliers d'identifiants par heure. Chaque requête provient d'une adresse IP différente, avec une chaîne user agent différente, ce qui la fait ressembler à un flux de tentatives de connexion légitimes provenant d'utilisateurs différents.
Pourquoi la limitation de débit échoue
La limitation de débit basée sur l'IP est la première ligne de défense que déploient la plupart des équipes, et c'est la première à échouer. Les services de proxies résidentiels donnent accès à des millions de vraies adresses IP — box domestiques, appareils mobiles et objets connectés — qui tournent à chaque requête. Du point de vue du serveur, chaque tentative de connexion provient d'une IP résidentielle unique sans historique d'abus.
La limitation de débit basée sur le compte (limiter les tentatives de connexion par nom d'utilisateur) est plus efficace mais crée un vecteur de déni de service : un attaquant peut verrouiller des utilisateurs légitimes en échouant délibérément plusieurs tentatives de connexion contre leurs noms d'utilisateur.
L'empreinte numérique d'appareil comme fondation
L'empreinte numérique d'appareil change la donne car elle identifie l'appareil qui exécute l'attaque, et non l'IP qu'il utilise. Un outil de credential stuffing exécuté sur une seule machine ou une ferme de VM produit une empreinte d'appareil cohérente sur toutes ses requêtes, quelle que soit l'IP de proxy par laquelle il tourne.
Notre moteur Bot Detection identifie les outils d'automatisation eux-mêmes. Selenium laisse des artefacts navigator.webdriver. Puppeteer et Playwright ont des caractéristiques distinctives de runtime JavaScript. Chrome headless est dépourvu de certaines API de navigateur que Chrome avec interface inclut. Même les clients HTTP personnalisés qui n'exécutent pas de JavaScript sont détectés par l'empreinte TLS — leurs messages Client Hello révèlent la bibliothèque HTTP sous-jacente.
Suivi de vélocité par appareil
Une fois que nous disposons d'un identifiant d'appareil stable (via Device Identification), nous pouvons appliquer des contrôles de vélocité au niveau de l'appareil plutôt qu'au niveau de l'IP. Si un seul appareil tente 50 connexions en 5 minutes — quel que soit le nombre d'IP différentes dont proviennent ces requêtes — le schéma est indéniablement du credential stuffing.
Notre module IP Intelligence suit la vélocité sur trois fenêtres temporelles : 5 minutes, 1 heure et 24 heures. Cette approche multi-fenêtres détecte à la fois les attaques agressives (des centaines de tentatives par minute) et les attaques lentes et discrètes (quelques tentatives par heure soutenues sur plusieurs jours).
Analyse des signaux comportementaux
Au-delà de la détection des bots et du suivi de vélocité, notre analyse Smart Signals examine des signaux comportementaux qui distinguent les attaques automatisées des connexions légitimes. Les vrais utilisateurs présentent une variation naturelle dans la temporisation des requêtes, la vitesse de frappe et les schémas de navigation. Les outils automatisés tendent à produire une temporisation mécaniquement constante, des en-têtes de requête identiques et aucun mouvement de souris ni événement de défilement.
Nous vérifions également les incohérences de signaux qui indiquent une falsification de l'environnement. Un navigateur prétendant être Chrome sur macOS mais présentant des paramètres WebGL associés à une VM Linux est signalé immédiatement. Une chaîne user agent qui ne correspond pas à l'empreinte TLS déclenche une alerte d'altération.
Déploiement en périphérie
La clé pour arrêter le credential stuffing est de l'arrêter avant qu'il n'atteigne votre système d'authentification. Notre agent se charge sur la page de connexion et collecte les signaux pendant le chargement de la page — avant que l'utilisateur (ou le bot) ne soumette les identifiants. Les résultats de l'empreinte et de la détection des bots sont disponibles au moment où le formulaire de connexion est soumis, permettant à votre serveur de rejeter instantanément les tentatives automatisées.
Pour les cibles à fort volume, nous recommandons de déployer notre intégration Cloudflare Worker ou CloudFront Lambda@Edge, qui exécute la validation d'empreinte en périphérie du CDN. Cela signifie que les requêtes de credential stuffing sont bloquées au nœud de périphérie le plus proche de l'attaquant, sans jamais atteindre vos serveurs d'origine.
Résultats
Nos clients rapportent une réduction de 99 % du volume de credential stuffing après avoir déployé tracio.ai sur leurs pages de connexion. Le 1 % restant est constitué d'attaques hautement sophistiquées utilisant une automatisation complète du navigateur avec des signaux soigneusement falsifiés — qui sont détectées par notre détection multi-méthodes dès les premières dizaines de requêtes à mesure que les schémas de vélocité apparaissent.