Clustraly
Authentification, 2FA & anti-intrusion

Coupez la force brute avec le verrouillage progressif après échecs et le rate-limiting à fenêtre glissante

Verrouillage progressif après échecs & rate-limiting à fenêtre glissante une fonctionnalité du module Authentification, 2FA & anti-intrusion de Clustraly. Défense anti-force-brute à deux étages : verrouillage IP escaladé selon les échecs et limiteur à fenêtre glissante par identifiant, renvoyant une réponse 429 normalisée.

Deux étages de défense anti-force-brute : le verrouillage progressif isole les adresses acharnées, le rate-limiting à fenêtre glissante plafonne chaque appelant et renvoie un 429 propre dès que la limite est franchie.

Le bénéfice

Coupez la force brute avant qu'elle n'aboutisse

Un attaquant qui martèle votre formulaire de connexion se heurte à deux murs successifs. Le premier verrouille l'adresse coupable, le second plafonne le débit de chaque appelant l'un ralentit, l'autre bloque.

Les deux étages s'appuient sur le journal des tentatives déjà tenu par le CMS : aucune configuration réseau, aucune dépendance externe.

  • Défense anti-force-brute à deux étages sur le formulaire de connexion
  • Verrouillage ciblé sur l'IP fautive, pas sur tout le trafic
  • Fonctionne sans pare-feu ni service tiers
Étage 1 Verrouillage progressif

Punissez l'acharnement, pardonnez l'erreur passagère

Les sanctions montent avec l'insistance. Trois échecs en 24 h verrouillent l'IP 30 minutes, six l'immobilisent une heure, dix la mettent à l'écart 24 heures. Un utilisateur qui se trompe une ou deux fois passe sans friction.

L'escalade ne s'applique qu'aux requêtes POST du bucket d'authentification : la navigation normale n'est jamais pénalisée.

  • 3 échecs / 24 h → 30 min, 6 → 1 h, 10 → 24 h
  • Compté par adresse IP, sur les seules soumissions de connexion
  • Le compteur d'échecs de l'IP est purgé dès une connexion réussie
Étage 2 Fenêtre glissante

Plafonnez le rythme, identifiant par identifiant

Un limiteur à compteur glissant mesure les requêtes de chaque appelant sur une minute mobile et refuse celles qui dépassent le quota. L'authentification est plafonnée à 10 par minute, l'API à 60, l'IA à 20.

Chaque appelant est reconnu par son identifiant de token, à défaut son identifiant utilisateur, à défaut son IP et chaque quota se surcharge par variable d'environnement.

  • auth 10/min · api 60/min · ai 20/min par défaut
  • Identité : token, puis utilisateur, puis IP
  • Quotas ajustables par variables d'environnement
La réponse

Renvoyez un 429 propre, dans le format de l'appelant

Au dépassement, le limiteur répond par un statut 429 accompagné des en-têtes Retry-After et X-RateLimit-Limit, -Remaining et -Reset. Le client sait exactement quand réessayer.

La réponse épouse l'appelant : JSON pour une API, page HTML pour un navigateur, enveloppe API pour vos intégrations.

  • Statut 429 avec Retry-After et X-RateLimit-Limit/Remaining/Reset
  • Rendu en JSON, HTML ou enveloppe API selon l'appelant
  • Le client connaît le délai exact avant nouvelle tentative
Les garde-fous

Ne verrouillez jamais vos utilisateurs légitimes

En cas d'erreur de stockage, le limiteur s'efface : la connexion continue de fonctionner via le journal des tentatives, même si la table des limites est absente. La sécurité ne devient jamais une panne.

Le compteur d'échecs récents par IP est exposé pour déclencher, au bon moment, l'affichage du CAPTCHA de connexion.

  • Fail-open : une panne de stockage ne bloque pas la connexion
  • recentFailedAttempts(ip) pilote l'apparition du CAPTCHA
  • Le journal des tentatives reste la source de vérité
Pourquoi ça compte

L'IA propose, vous décidez

Clustraly applique des seuils éprouvés 3, 6 puis 10 échecs, 10/60/20 requêtes par minute et vous laisse chaque valeur en main via les variables d'environnement. Vous durcissez ou assouplissez chaque bucket sans toucher au code.

FAQ

Questions fréquentes

Que se passe-t-il après plusieurs échecs depuis une même adresse IP ?
Le verrouillage progressif immobilise l'IP : 30 minutes dès 3 échecs sur 24 heures, 1 heure à 6 échecs, 24 heures à 10. Une connexion réussie purge ensuite le compteur d'échecs de l'IP.
Le rate-limiting compte-t-il par utilisateur ou par adresse IP ?
Par identifiant, dans cet ordre : l'identifiant du token s'il est présent, sinon l'identifiant de l'utilisateur, sinon l'adresse IP. Chaque appelant a donc son propre compteur à fenêtre glissante.
Que reçoit un client qui dépasse le quota ?
Une réponse HTTP 429 avec les en-têtes Retry-After et X-RateLimit-Limit, -Remaining et -Reset, formatée en JSON, HTML ou enveloppe API selon l'appelant.
Un problème sur la table des limites peut-il bloquer les connexions ?
Non. Le limiteur est fail-open : en cas d'erreur de stockage, la connexion continue via le journal des tentatives, même si la table des limites est absente.
Prêt à commencer ?

Deux murs contre la force brute, zéro friction pour vos utilisateurs

Le verrouillage progressif isole les IP acharnées, le rate-limiting à fenêtre glissante plafonne chaque appelant, et le 429 normalisé parle le langage de vos clients. Les seuils restent les vôtres, ajustables à tout moment par variables d'environnement. L'IA propose, vous décidez.