La page de connexion est la porte la plus sondée que possède votre organisation
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é.
Notre approche
Friction graduée, politique multi-portée et challenge self-hosted — tout sur la plateforme que vous possédez déjà.
Trois niveaux de friction, pas un seul mur dur
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.
Trois portées — adaptez la défense à l'attaque
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.
CAPTCHA self-hosted — aucun cloud de détection bot externe
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.
Coordonné avec le MFA et le reste du chemin d'authentification
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é.
Capacités
Politiques multi-portées — IP, nom d'utilisateur, ou combiné
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.
Seuils graduels — avertissement, CAPTCHA, verrouillage
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.
CAPTCHA image self-hosted avec cinq niveaux de difficulté
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.
Aucun CAPTCHA tiers ni cloud de détection bot dans le chemin d'authentification
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.
Suivi coordonné des tentatives sur le flux d'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é.
Fenêtre de décroissance par tentative — les anciens échecs s'oublient d'eux-mêmes
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.
Piste d'audit par tentative avec contexte du destinataire masqué
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.
Profondeur opérationnelle
Les mécanismes qui rendent la défense graduée invisible pour les bons utilisateurs et claire pour les attaquants.
L'apparence du CAPTCHA est personnalisable par marque
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 exclut délibérément les caractères confus
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é.
Seuils, décroissance et durée de verrouillage par politique
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.
Coordination sans état via Redis
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.
Flux de récupération — déverrouillage administrateur et libération temporelle
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.
Où les équipes l'utilisent
Credential stuffing sur de nombreux comptes
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.
Force brute contre un compte connu
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.
Connexions spam pilotées par des bots
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.
Preuves de conformité sur la surveillance des connexions
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.
Questions fréquentes
Quels patterns d'attaque sont couverts ?
Le niveau CAPTCHA utilise-t-il Google reCAPTCHA ou Cloudflare Turnstile ?
Quand devrais-je utiliser la portée IP vs la portée username vs la portée combinée ?
Comment un utilisateur se remet-il d'un verrouillage ?
Quand le compteur de tentatives échouées se réinitialise-t-il ?
Défendez la page de connexion sans verrouiller les vrais utilisateurs
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.