Limitation de débit : arrêter le bourrage d'identifiants et la force brute

Une attaque qui n’exploite aucune faille de votre code

Le bourrage d’identifiants (credential stuffing) est déroutant parce qu’il ne casse rien chez vous. L’attaquant part d’une liste de couples e-mail/mot de passe fuités ailleurs — une autre entreprise, une autre fuite — et les rejoue en masse sur votre page de connexion en pariant sur la réutilisation des mots de passe. Chaque tentative est une requête HTTP parfaitement valide. Votre code fonctionne comme prévu ; c’est le volume et le pattern qui constituent l’attaque.

La force brute classique est la cousine plus grossière : au lieu d’une liste de mots de passe déjà connus, l’attaquant en essaie des milliers contre un même compte. Dans les deux cas, la défense n’est pas une signature d’attaque — il n’y a rien de « malveillant » dans une requête isolée — mais le contrôle du rythme et de la distribution des tentatives.

Pourquoi une simple limite par IP ne suffit plus

La première idée est de compter les tentatives par adresse IP et de bloquer au-delà d’un seuil. Ça arrête l’amateur. Mais un attaquant sérieux répartit ses tentatives sur des milliers d’adresses résidentielles : une seule tentative par IP, jamais deux fois la même, sous n’importe quel seuil par adresse. La limite par IP ne voit rien.

Une limitation de débit efficace regarde donc plusieurs dimensions à la fois :

• Par identité ciblée. Cinquante IP différentes qui tentent toutes de se connecter au même compte en quelques minutes, c’est une attaque contre ce compte — peu importe qu’aucune IP ne dépasse son quota. Compter par identifiant visé révèle ce que le comptage par IP masque.
• Par forme de campagne. Un pic soudain d’échecs de connexion à travers tout le site, avec un taux de succès anormalement bas, est la signature d’une liste rejouée. Le scoring d’entité par apprentissage agrège ces signaux dans le temps au lieu de juger chaque requête isolément.
• Par géographie et réputation. Une vague qui arrive depuis des réseaux jamais vus pour votre base d’utilisateurs mérite un traitement différent d’un client habituel.

Répondre par des marches, pas par un mur

Bloquer sèchement au premier soupçon punit les vrais utilisateurs qui se trompent de mot de passe. La bonne réponse est graduée. À la périphérie, un client suspect gravit une échelle de défis — preuve de travail, puis CAPTCHA, puis authentification de robot vérifié. Un humain qui a juste raté sa connexion passe le défi sans effort réel ; une machine qui rejoue dix mille couples voit son coût exploser à chaque tentative. L’attaque devient économiquement absurde bien avant d’être « bloquée ». Le mécanisme complet est décrit dans l’article sur l’échelle de défis.

Techniquement, ce contrôle vit dans le chemin chaud de la requête : un compteur en mémoire partagée sur chaque nœud d’abord, un compteur distribué ensuite pour la vue inter-nœuds. La décision se prend en microsecondes, dans notre budget de conception de ≤5 ms, mesuré en staging et jamais présenté comme un benchmark de production.

La traçabilité, pas seulement le blocage

Quand une campagne de bourrage frappe, votre équipe sécurité a besoin de répondre à des questions précises : combien de comptes visés, combien de tentatives réussies, depuis quand. Chaque décision de limitation est inscrite dans un journal d’audit immuable, en ajout seul. Pour une entreprise soumise au RGPD, cette piste vérifiable — hébergée sur des nœuds européens — fait la différence entre une notification d’incident documentée et une supposition. Voyez comment nous traitons la journalisation conforme au RGPD.

Ce que nous ne prétendons pas

La limitation de débit rend le bourrage d’identifiants coûteux et visible ; elle ne remplace pas l’authentification à plusieurs facteurs ni une politique de mots de passe saine. Un compte protégé par un second facteur survit même si le mot de passe est rejoué avec succès — et c’est la défense de fond que rien à la périphérie ne remplace. Nous ne promettons pas non plus un taux d’arrêt chiffré : les campagnes évoluent, et un pourcentage « garanti » serait une promesse malhonnête.

Vous voulez voir combien de connexions frauduleuses frappent déjà votre page de login ? Donnez-nous votre domaine.