Chaque page de connexion publique commence à être scannée par des outils automatisés peu après sa mise en ligne. Les attaquants essaient des noms d'utilisateur et mots de passe précédemment fuités, martèlent un seul compte avec des suppositions de mots de passe, ou utilisent des bots pour abuser du formulaire de connexion.
Ces attaques n'ont pas la même apparence. Parfois de nombreuses tentatives proviennent d'une seule adresse IP. Parfois le même nom d'utilisateur est réessayé depuis de nombreuses sources différentes. Parfois des mots de passe fuités sont appliqués à des milliers de comptes différents à faible vitesse, selon un pattern distribué.
C'est pourquoi les défenses statiques sont insuffisantes. Verrouiller uniquement par IP manque les attaques distribuées et peut bloquer à tort de vrais utilisateurs venant via des réseaux partagés. Verrouiller uniquement par compte donne aux attaquants un autre avantage — ils peuvent verrouiller de nombreux comptes et provoquer un déni de service. Forcer un CAPTCHA à chaque connexion unique ruine l'expérience du vrai utilisateur.
La plus grande erreur est de laisser l'évaluation des bots et des risques au moment de la connexion entièrement à un service cloud tiers. Ce modèle crée une dépendance externe, un coût par utilisateur ou par évaluation, des problèmes de visibilité des données, et un point de rupture supplémentaire dans le chemin d'authentification.
La protection des connexions ne devrait pas être un mur uniforme. Ce devrait être une couche de sécurité locale qui augmente la friction à mesure que le risque augmente, répond en fonction de la source et de la cible de l'attaque, et ne pénalise pas inutilement les vrais utilisateurs.
Parce que protéger la page de connexion ne consiste pas seulement à arrêter l'attaquant — il s'agit aussi de permettre au vrai utilisateur de continuer son travail en toute sécurité.
Friction graduée, politique multi-portée et challenge self-hosted — tout sur la plateforme que vous possédez déjà.
Chaque politique exécute trois seuils : un avertissement qui apparaît dans le journal d'audit, un CAPTCHA challenge qui filtre l'automatisation sans bloquer les humains, et un verrouillage qui ferme complètement la porte. Les utilisateurs légitimes voient rarement le deuxième niveau et presque jamais le troisième ; les attaquants escaladent rapidement.
Chaque politique s'applique à l'une des trois portées : par IP source, par nom d'utilisateur, ou par les deux ensemble. Une attaque par force brute sur un compte depuis une IP est capturée par la portée IP ; le credential stuffing sur de nombreux noms d'utilisateur depuis des IPs rotatives est capturé par la portée username ; la portée combinée gère les attaques ciblées qui mélangent les deux.
Le CAPTCHA challenge est généré côté serveur sous forme d'image, avec cinq niveaux de difficulté, un jeu de caractères qui omet les caractères confus (I, L, O, 0, 1), et des couleurs, dimensions et bruits configurables. Il n'y a ni Google reCAPTCHA, ni Cloudflare Turnstile, ni frais par évaluation — et le moment le plus sensible de l'authentification ne quitte jamais votre périmètre.
Les compteurs de tentatives de verrouillage se coordonnent avec le même suivi des tentatives utilisé par chaque canal MFA. Un utilisateur ne peut pas faire de force brute sur un facteur pendant qu'une autre tentative attend en parallèle, et un captcha déclenché à l'étape mot de passe se propage au reste du flux qui protège la même identité.
Les primitives de défense en détail, ainsi que la feuille de route qui les approfondira.
Chaque politique est liée à l'une des trois portées. La portée IP capture un seul attaquant martelant de nombreux comptes depuis un réseau. La portée username capture le credential stuffing où chaque tentative fait tourner l'IP source. La portée combinée capture le cas ciblé où un attaquant connu se concentre sur un compte spécifique depuis un réseau spécifique.
Chaque politique exécute trois seuils qui escaladent dans l'ordre. Le seuil d'avertissement signale une activité suspecte dans le journal d'audit sans affecter l'utilisateur. Le seuil CAPTCHA place un challenge image self-hosted devant la prochaine tentative. Le seuil de verrouillage ferme la porte pour une durée configurable — et l'ordre, les valeurs et la fenêtre de décroissance sont tous définis par politique.
Les CAPTCHAs sont générés localement sous forme d'images — cinq niveaux de difficulté de légères aides à la lisibilité jusqu'à une forte distorsion, couleurs et dimensions configurables pour correspondre à la marque, et un jeu de caractères qui omet intentionnellement les caractères visuellement similaires (I, L, O, 0, 1) pour garder l'expérience de l'utilisateur légitime propre.
La protection des connexions est générée, servie, validée et auditée entièrement sur la plateforme. Il n'y a aucun frais par évaluation, aucune dépendance extérieure, aucune implication sur la confidentialité d'envoyer chaque tentative de connexion à un fournisseur, et aucun service de scoring opaque entre vos utilisateurs et votre authentification.
Les tentatives de mot de passe échouées, les challenges MFA échoués et les réponses CAPTCHA échouées alimentent des compteurs coordonnés par portée de politique. Un attaquant ne peut pas faire de force brute sur un facteur pendant qu'une tentative parallèle attend à un autre, et un verrouillage déclenché à une étape se propage à chaque canal qui protège la même identité.
Chaque politique définit une fenêtre de décroissance. Les tentatives échouées plus anciennes que la fenêtre cessent de compter pour les seuils actuels, de sorte qu'un utilisateur légitime qui a mal tapé son mot de passe trois fois la semaine dernière ne commence pas aujourd'hui déjà au niveau CAPTCHA. La fenêtre, la forme de la décroissance et les seuils sont tous ajustables par politique.
Chaque tentative de connexion — succès, avertissement franchi, CAPTCHA déclenché, verrouillage déclenché — écrit une entrée d'audit structurée avec l'horodatage, l'IP source, le user agent, la portée et le résultat de la politique. Les informations du destinataire (e-mail, téléphone) sont masquées par défaut dans le flux d'audit pour que la piste d'audit ne devienne pas un chemin de fuite secondaire.
Un moteur de corrélation planifié liera les compteurs de tentatives entre services, de sorte qu'un attaquant qui teste des identifiants contre une application de faible valeur ne peut ensuite pas passer à une application de haute valeur avec une ardoise propre. Les flux de réputation IP se brancheront sur le même moteur de politique pour escalader automatiquement la friction pour les réseaux malveillants connus.
Les mécanismes qui rendent la défense graduée invisible pour les bons utilisateurs et claire pour les attaquants.
La couleur d'arrière-plan, la couleur du texte, la largeur, la hauteur, la taille de police, l'espacement des caractères, les lignes de bruit et les points de bruit sont tous configurables. Le challenge peut correspondre à l'identité visuelle du portail de connexion qu'il protège sans révéler qu'un service externe est impliqué — parce que rien d'externe n'est impliqué.
Le jeu de caractères par défaut omet I, L, O, 0 et 1 — des caractères faciles à confondre entre eux sous forme distordue. Les utilisateurs légitimes résolvent les CAPTCHAs plus vite et avec moins de tentatives ; la valeur défensive contre les solveurs automatisés est préservée à chaque niveau de difficulté.
Le seuil d'avertissement, le seuil CAPTCHA, le seuil de verrouillage, la fenêtre de décroissance et la durée de verrouillage sont tous configurables par politique. Une interface de gestion des utilisateurs a des tolérances différentes d'une connexion de service d'assistance publique ou d'une console d'administration ; le même moteur les sert avec des valeurs différentes.
Les compteurs et l'état de verrouillage vivent dans Redis, de sorte que tout pod gateway peut voir le nombre de tentatives actuel pour n'importe quelle portée. Les déploiements à mise à l'échelle horizontale voient un état cohérent sans surcharge de coordination, et une décision de verrouillage prise sur un pod est immédiatement visible pour chaque autre pod.
Un utilisateur verrouillé attend soit que le verrouillage expire selon sa propre horloge, soit est déverrouillé par un administrateur via l'interface d'administration de la gateway. L'action de récupération est elle-même auditée ; un déverrouillage d'urgence lors d'un incident est un événement traçable plutôt qu'une solution de contournement invisible.
Des seuils adaptatifs qui se resserrent automatiquement lorsqu'une source de renseignement sur les menaces en amont signale un risque accru — réseaux malveillants connus, campagnes actives de credential stuffing, listes d'identifiants fuités — sont sur la feuille de route. Le même moteur de politique reçoit le signal ; la même piste d'audit enregistre le changement.
Un attaquant avec une liste de noms d'utilisateur/mots de passe fuités fait tourner les IPs et essaie chaque paire contre la page de connexion. Les politiques de portée username capturent ce pattern — les compteurs augmentent par compte, le niveau CAPTCHA filtre l'automatisation, et le verrouillage ferme la porte pour les cibles répétées.
Un seul attaquant, une seule IP source, un seul compte cible, de nombreuses suppositions. Les politiques de portée IP capturent ceci en quelques secondes — l'avertissement remonte dans l'audit, le niveau CAPTCHA filtre les tentatives scriptées, et la durée de verrouillage se multiplie assez vite pour rendre l'attaque non économique.
Des agents automatisés tentent de se connecter pour scraper, spammer ou attendre un compte déverrouillé. Le niveau CAPTCHA est exactement là où ceux-ci sont capturés — généré localement, validé localement, et entièrement hors de portée des services de résolution automatique de CAPTCHA qui ciblent les challenges SaaS externes.
PCI DSS, HIPAA et ISO 27001 exigent des preuves que la surveillance des échecs de connexion est en place, avec des seuils et des pistes d'audit. Le flux d'audit par tentative donne à l'auditeur une seule chronologie à examiner, avec des seuils exprimés comme configuration plutôt que sous forme de prose écrite.
Friction graduée en trois niveaux, couverture de politique en trois portées et CAPTCHA self-hosted — tout sur la plateforme que vous possédez déjà. Nous présenterons un déploiement en direct sur vos applications.