La force brute classique effectue de nombreuses tentatives de mot de passe en peu de temps depuis une seule IP. Le credential stuffing essaie la même liste de mots de passe distribuée sur de nombreuses IP. Les attaques low-and-slow effectuent un petit nombre de tentatives sur des heures. Les tentatives de détournement de session se révèlent après une connexion réussie via des changements d'IP, de user agent ou de comportement. Capturer tout cela avec la même règle de rate limit n'est pas réaliste.
Utiliser uniquement le verrouillage basé sur l'IP laisse passer le credential stuffing distribué et affecte injustement les utilisateurs légitimes sur des réseaux partagés. Utiliser uniquement le verrouillage basé sur l'utilisateur permet aux attaquants de déclencher intentionnellement le verrouillage de compte comme un déni de service. Utiliser uniquement le CAPTCHA transforme chaque tentative de connexion en friction inutile et dégrade l'expérience utilisateur.
De nombreuses solutions ne regardent que le moment de la connexion. Pourtant le risque de prise de contrôle de compte continue après la connexion : si des actions sensibles telles que le changement de mot de passe, le changement d'e-mail, l'ajout de méthode de paiement, la génération de token API ou le virement de fonds arrivent dans un nouveau contexte, c'est un signal d'abus post-connexion. Ce comportement doit être évalué conjointement avec le session binding et le step-up MFA.
La bonne approche est d'utiliser la bonne combinaison de portée et de signal pour chaque classe d'attaque. Les portées IP, username, username_ip et composite doivent fonctionner ensemble avec le score bot, la vélocité d'authentification échouée, la réputation IP et la non-concordance de session binding.
TR7 Account Takeover Protection délivre ce modèle : il combine les signaux de trafic WAAP avec les politiques d'accès AAM et gère le risque ATO via un graphe de politique multi-couches plutôt qu'une seule règle.
TR7 applique la défense ATO via un scoring multi-signaux, la sélection de portée spécifique à la classe d'attaque, l'escalade graduée et la coordination AAM.
Le score bot, la vélocité d'authentification échouée, la réputation IP et la non-concordance de session binding sont tous évalués sur le même chemin de décision. Les décisions sont prises en fonction de la forme comportementale réelle de l'attaque — pas uniquement sur l'IP ou uniquement sur le nom d'utilisateur.
La portée IP suit les tentatives de force brute depuis une seule source, la portée username suit le credential stuffing distribué, la portée username_ip suit les attaques ciblées, et la portée composite suit les combinaisons d'IP, user agent et headers. Chaque portée opère avec ses propres compteurs et comportement de seuil.
Dans la première étape, l'événement est écrit dans le journal d'audit, puis le CAPTCHA self-hosted est activé, et enfin le verrouillage est appliqué. Ce modèle ralentit l'attaquant tout en minimisant la friction inutile pour les utilisateurs légitimes.
Les signaux de trafic WAAP peuvent fonctionner en parallèle avec les politiques de verrouillage et de step-up MFA d'AAM. Une vérification supplémentaire peut être déclenchée pour les utilisateurs approchant le seuil CAPTCHA ou présentant un changement de contexte de session.
Account Takeover Protection réunit le risque de trafic pré-connexion, les échecs de connexion et le comportement de session post-connexion dans la même chaîne de protection.
TR7 rend la défense ATO graduée via le flux avertissement → CAPTCHA → verrouillage. L'étape d'avertissement produit une piste d'audit sans présenter de friction à l'utilisateur. L'étape CAPTCHA challenge l'automatisation et offre aux utilisateurs légitimes une étape de vérification contrôlée. L'étape de verrouillage suspend temporairement la capacité de tentative pour la portée spécifique.
Les attaques ATO ne peuvent pas être capturées par une seule portée. TR7 peut exécuter simultanément des politiques de portée basées sur l'IP, le nom d'utilisateur, l'IP+nom d'utilisateur et la portée composite sur le même endpoint. La force brute depuis une seule IP, le credential stuffing multi-IP et les attaques ciblées de compte sont chacun suivis séparément. Même si un attaquant reste sous une portée, l'autre portée peut toujours détecter le comportement.
Le déclencheur failedAuthAttempts compte les tentatives échouées dans une fenêtre temporelle définie. Ce compteur peut être suivi par utilisateur, par IP ou par portée composite. Les courtes fenêtres exposent les tentatives de force brute rapide ; les longues fenêtres révèlent les comportements ATO low-and-slow. Le comptage total et la densité des tentatives dans le temps alimentent la décision.
TR7 peut prendre en compte l'analyse du user agent, la réputation IP, l'analyse du comportement, le chemin suspect, l'empreinte du header, les anomalies de protocole, les incohérences de signal, le nœud de sortie Tor, l'empreinte TLS et l'IP de datacenter lors du calcul du score bot. Lorsque le score atteint un niveau défini, une action CAPTCHA ou de blocage peut être déclenchée. Les tentatives de connexion sont évaluées non seulement comme des erreurs de mot de passe mais aussi comme un comportement d'automatisation, intégrant la qualité du trafic dans la défense ATO.
Des sous-catégories de réputation IP telles que proxy ouvert, mauvais bot, attaque, reconnaissance, spam et IP VPN peuvent être utilisées comme signaux de risque dans les décisions ATO. Ces catégories n'ont pas à produire un blocage obligatoire à elles seules ; elles sont évaluées conjointement avec le score bot et les politiques de verrouillage. Les tentatives de connexion depuis une infrastructure connue comme malveillante peuvent être soumises à une friction plus précoce. Cette approche fonctionne en combinaison avec d'autres signaux pour réduire le risque de faux positifs.
Le martelage de chemins, les requêtes rapides, le taux élevé de 404, les requêtes de mutation sans referer et l'utilisation de méthodes HTTP inattendues peuvent tous être des signaux de risque sur la surface de connexion. Ces indicateurs aident à distinguer le credential stuffing, l'énumération de comptes et les comportements d'analyse automatisée. Les signaux ne sont pas évalués isolément — ils fonctionnent conjointement avec le score bot et les compteurs d'authentification échouée. L'attaque devient visible non seulement par les erreurs de mot de passe mais aussi par le comportement du trafic.
Lorsque le seuil CAPTCHA est dépassé, TR7 peut activer son propre flux de challenge. Un challenge contrôlé est présenté à l'utilisateur sans envoyer de données à un service de vérification externe. Les réponses CAPTCHA incorrectes peuvent être ajoutées au compteur de tentatives échouées et accélérer l'escalade. Cela offre un modèle plus contrôlé pour les organisations avec des exigences de résidence des données et de sensibilité réglementaire.
TR7 peut coordonner les signaux bot WAAP et de verrouillage avec les politiques d'accès AAM. Le step-up MFA peut être déclenché pour les utilisateurs approchant le seuil CAPTCHA, générant une anomalie de session binding ou effectuant une action sensible. Cette approche porte le risque au moment de la connexion dans les opérations post-connexion également. Même si l'attaquant connaît le bon mot de passe, il fait toujours face à la barrière de vérification supplémentaire.
Une session peut être associée à une IP, une IP+user agent ou un contexte composite. Si l'IP, le user agent ou le contexte change de manière inattendue après la connexion, une anomalie de session binding peut être générée. Ce signal est particulièrement important dans les scénarios de détournement de session et de réutilisation de token. La ré-authentification ou des contrôles supplémentaires peuvent être déclenchés sur les endpoints sensibles.
attemptWindowDuration définit combien de temps les tentatives échouées continuent à être comptées. Si un utilisateur fait quelques erreurs de mot de passe aujourd'hui, il peut revenir à un comportement propre une fois la fenêtre expirée. Un attaquant qui accumule suffisamment de tentatives dans la même fenêtre rencontre un CAPTCHA ou un verrouillage. Ce modèle établit un équilibre plus sain entre sécurité et expérience utilisateur.
Pour chaque tentative de connexion, l'horodatage, l'IP source, le user agent, la portée, l'ID de politique et le résultat peuvent être enregistrés. Les résultats tels qu'avertissement, CAPTCHA, verrouillage ou passage réussi sont distingués lors de l'examen d'incident. Les détails du destinataire tels que l'e-mail ou le numéro de téléphone sont masqués pour que le journal d'audit ne devienne pas un canal secondaire de fuite de données. Les équipes SOC suivent les flux d'attaques en utilisant des enregistrements structurés.
Si une action de quarantaine est définie après l'expiration de la période de verrouillage, le client ou la portée peut être placé sous un examen supplémentaire. Cela rend plus difficile pour les attaquants de répéter les mêmes tentatives à chaque fois que la durée de verrouillage se termine. La quarantaine fournit un suivi continu des risques au-delà du comportement de verrouillage classique et constitue une couche supplémentaire utile dans les campagnes ATO de longue durée.
La protection ATO est opérée conjointement avec des préréglages de politique prêts à l'emploi, des compteurs natifs, la courbe de score bot, l'isolation de pool, la portée composite et le partage de compteurs AAM.
TR7 peut fournir des exemples de politique de verrouillage prêts à l'emploi pour les portées username, IP et username_ip. La portée username se concentre sur le credential stuffing avec une fenêtre plus longue ; la portée IP se concentre sur le comportement de force brute avec une fenêtre plus courte. Tous les seuils, durées et actions peuvent être ajustés aux besoins du service.
Les tentatives de connexion échouées sont suivies à l'aide de structures de compteur rapides. Cette approche réduit la dépendance aux appels de base de données externes et fournit une faible latence sur le chemin de connexion. La réplication des compteurs vers les nœuds pairs dans un environnement cluster est importante pour la continuité de la protection après un basculement.
Le score bot peut être interprété comme sensible à de faibles niveaux de signal et saturant à mesure que le risque élevé s'accumule. Cette approche permet à de nombreux petits signaux de se composer en risque significatif. Lorsqu'un nouveau signal est ajouté, le besoin de repenser l'ensemble du seuil de politique depuis le début est réduit.
Chaque pool peut être lié à son propre profil de protection du trafic. Un signal ATO sur un locataire ou service n'affecte pas les compteurs d'un autre locataire. Cette isolation est critique dans les scénarios SaaS multi-locataire et MSP.
La portée composite peut combiner l'IP, le user agent, l'accept-language ou des composants de header similaires en une seule clé de suivi. Ce modèle fournit un suivi plus contextuel lorsque l'IP ou le nom d'utilisateur seul est insuffisant. Il offre une visibilité supplémentaire contre les user agents rotatifs ou le comportement client variable.
Les compteurs d'authentification échouée WAAP peuvent être coordonnés avec les politiques de verrouillage AAM. Même si un attaquant cible directement différents endpoints de connexion, le même comportement de risque peut être évalué sur le compteur partagé et le chemin de politique. Cela rend la protection ATO cohérente non seulement au niveau de la couche de trafic mais aussi tout au long du flux d'identité.
Les équipes bancaires peuvent surveiller les endpoints de connexion avec la portée IP et le comportement de connexion SSL ensemble. Lorsque les seuils définis sont dépassés, le CAPTCHA, le verrouillage ou le step-up MFA d'AAM est activé.
Les bots effectuant un petit nombre de tentatives depuis de nombreuses IP peuvent ne pas apparaître sous la portée IP. La portée username capture les tentatives échouées s'accumulant sur le même compte et applique un CAPTCHA ou un verrouillage au niveau du compte.
Des tentatives à faible volume mais focalisées contre un compte de directeur financier ou d'administrateur peuvent être suivies avec la portée username_ip ou composite. Lorsque le risque augmente, le step-up MFA est déclenché via AAM.
Si l'IP ou le user agent change de manière inattendue immédiatement après la connexion d'un utilisateur, une anomalie de session binding peut être générée. Une ré-authentification peut être requise pour des actions telles que les virements de fonds, les changements d'e-mail ou la génération de tokens.
Défense ATO intégrée contre le credential stuffing, la force brute, les attaques low-and-slow et le détournement de session. Parcourons ensemble une configuration en direct sur vos propres services.