Credential stuffing : la mécanique réelle, et pourquoi le rate limiting par IP ne
suffit plus

Le réflexe, quand un formulaire de connexion se fait marteler, est de compter les tentatives par adresse IP et de bloquer au-delà d'un seuil. Ce compteur a rendu de vrais services pendant vingt ans, et contre le credential stuffing il ne fait plus rien, pour une raison qui n'a aucun rapport avec le volume : les mots de passe testés sont vrais. Ils ont été saisis par les personnes visées, sur un autre service, et ils sont rejoués tels quels, à raison d'un essai par compte. Rien n'est deviné, rien n'est cassé.

L'ampleur, elle, se mesure. La recherche complémentaire publiée par Verizon avec son DBIR 2025 impute au credential stuffing, sur deux ans de télémétrie, une médiane quotidienne de 19 % des tentatives d'authentification : 12 % chez les petites structures, jusqu'à 25 % chez les grandes, avec une journée record à 44 %. Sur beaucoup de formulaires de connexion exposés, une tentative sur cinq n'est pas un utilisateur qui se trompe de mot de passe.

Credential stuffing, brute force, password spraying : trois choses distinctes

OWASP, dans son référentiel des menaces automatisées, sépare explicitement deux codes. Le credential stuffing y porte le numéro OAT-008 et se définit comme "mass log in attempts used to verify the validity of stolen username/password pairs", avec une précision qui vaut tout le reste de la fiche : "unlike OAT-007 Credential Cracking, Credential Stuffing does not involve any brute-forcing or guessing of values ; instead credentials used in other applications are being tested for validity" (OWASP Automated Threats, OAT-008). Le verbe est verify, pas guess. Toute la mécanique découle de là.

Le password spraying, lui, est un troisième animal, souvent confondu avec les deux autres parce qu'il partage avec le stuffing la volumétrie horizontale. Il devine, comme le brute force, mais il inverse les axes : au lieu de mille mots de passe sur un compte, il essaie deux ou trois mots de passe très courants (l'éternel Automne2026!) sur dix mille comptes, pour rester sous les seuils de verrouillage.

                      BRUTE FORCE        PASSWORD SPRAYING     CREDENTIAL STUFFING
                      (OAT-007)                                (OAT-008)

comptes visés         1 (ou quelques-uns) beaucoup             beaucoup
mots de passe/compte  des milliers        2 a 3                1 (parfois 2)
origine du mdp        genere / dictio.    liste des + courants fuite d'un TIERS
le mdp est...         devine              devine               reel, deja saisi
                                                               par la personne

trace laissee         rafale d'echecs     meme mdp sur N       1 essai isole
                      sur UN compte       comptes distincts    par compte

seuil de lockout      declenche           contourne par        jamais approche
                                          construction

filtrer les mdp       inefficace          EFFICACE             inefficace
les plus courants                                              (le mdp est unique)

quand ca reussit      compte faible       compte a mdp banal   compte a mdp REUTILISE

La dernière ligne est celle qui décide de tout. Un stuffing qui réussit ne sanctionne pas un mot de passe faible : il sanctionne un mot de passe réutilisé. Une phrase de passe de quarante caractères, unique et soigneusement générée, tombe comme azerty123 dès lors qu'elle a servi ailleurs et que cet ailleurs a fuité. La conséquence porte directement sur les politiques de mot de passe : imposer de la complexité n'a aucun effet sur cette classe d'attaque.

D'où sortent les combo lists

La matière première s'appelle une combo list : un fichier plat de couples identifiant et mot de passe, en clair, agrégé depuis plusieurs fuites de bases tierces, dédoublonné, puis découpé. Découpé par domaine de messagerie quand l'attaquant vise un fournisseur en particulier, par pays, ou par service quand la source le permet. Les variantes issues de logiciels voleurs d'informations vont plus loin : elles conservent l'URL sur laquelle le couple a été saisi, ce qui supprime l'étape de devinette du formulaire cible.

Ces fichiers ne sont pas des trophées rares, ils sont un consommable. Les mécanismes qui les alimentent en amont, base exfiltrée, dépôt de code trop bavard, machine infectée, sont détaillés dans notre pilier sur les fuites de secrets et de credentials exposés, et leur circulation dans les canaux fermés dans notre article sur la surveillance du dark web. Le phishing alimente le même stock, avec une différence de qualité notable : un identifiant hameçonné est frais et ciblé, là où une combo list est massive et largement périmée. Quand la page de collecte se fait passer pour une marque connue, on est déjà dans l' usurpation d'identité d'entreprise, qui a ses propres canaux de traitement.

Reste le paramètre qui décide du rendement, et il ne dépend ni de l'attaquant ni de vous : le taux de réutilisation. La même recherche DBIR 2025 le chiffre, et le chiffre fait mal : en médiane, seulement 49 % des mots de passe d'un utilisateur sont distincts d'un service à l'autre. Une personne sur deux, environ, recycle. À l'échelle d'une base clients, c'est une garantie statistique de rendement. L'étude Google et Stanford présentée à USENIX Security 2019, celle qui a donné naissance à Password Checkup, mesurait de son côté que 1,5 % des connexions analysées utilisaient un identifiant déjà présent dans une fuite connue, sur plus de 746 000 domaines différents.

L'économie de l'attaque : pourquoi un rendement dérisoire suffit

Le taux de réussite du credential stuffing est misérable. Le coût unitaire d'une tentative l'est encore plus, et c'est ce rapport qui fait tourner l'industrie. Akamai, dans son rapport State of the Internet "Phishing for Finance" publié en mai 2021, comptabilisait 193 milliards de tentatives de credential stuffing sur l'année 2020, dont 3,4 milliards visant les seuls services financiers, en hausse de plus de 45 % sur un an dans ce secteur. À cette échelle, un rendement de quelques dixièmes de pour cent produit encore des dizaines de milliers de comptes pris.

Côté outillage, l'écosystème s'est industrialisé autour de frameworks de test d'identifiants, dont OpenBullet est le représentant le plus connu, et surtout autour des configs : des descripteurs, échangés ou vendus, qui encodent la séquence de connexion d'un site donné. Quels champs, quel jeton anti-CSRF récupérer avant, quelle réponse signe un succès, quelle réponse signe un compte inexistant. Peu importe l'outil ; ce qui compte, c'est ce qu'implique l'existence d'une config pour votre site. Le comportement de votre formulaire d'authentification est alors un savoir public, documenté, maintenu par des tiers. Vos réponses HTTP sont lues avec plus d'attention par eux que par vos propres développeurs.

La dernière brique, c'est le réseau. Les campagnes sérieuses passent par des pools de proxys résidentiels, c'est-à-dire des adresses IP appartenant à de vrais abonnés grand public, louées à l'heure ou au gigaoctet, souvent recrutées via des applications gratuites ou des SDK embarqués. Sortie géolocalisée dans le bon pays, réputation d'IP propre, et rotation à chaque requête.

Pourquoi le rate limiting par IP ne protège plus

L'arithmétique est courte. Une campagne d'un million de tentatives répartie sur un pool de 100 000 adresses résidentielles, c'est dix tentatives par adresse sur toute la durée de la campagne. Si la campagne s'étale sur trois jours, on tombe à trois tentatives par IP et par jour. Aucun seuil de rate limiting ne descend là : à ce niveau, vous bloqueriez d'abord vos propres utilisateurs.

Le problème du dommage collatéral est plus grave qu'on ne le croit, parce que le trafic légitime est lui aussi concentré derrière peu d'adresses. Une entreprise de 400 personnes sort par une poignée d'IP ; un opérateur mobile agrège des dizaines de milliers d'abonnés derrière un même CGNAT. Un seuil assez bas pour gêner un pool de proxys transforme mécaniquement votre plus gros client B2B en faux positif. La grandeur que mesure ce compteur a cessé d'être corrélée à l'intention, et aucun réglage de seuil ne rétablit cette corrélation.

Deuxième angle mort, plus prosaïque : le formulaire web protégé n'est généralement pas le seul chemin vers la vérification d'un mot de passe. Il reste l'API mobile, un ancien /oauth/token laissé ouvert pour un partenaire, un endpoint de connexion legacy oublié sur un sous-domaine, et parfois un simple formulaire de récupération de mot de passe qui répond différemment selon que l'adresse existe ou non. Les attaquants cherchent la porte non instrumentée, pas la porte principale, et c'est le raisonnement décrit dans notre article sur l' exposition des API et la façon de les tester.

Se protéger du credential stuffing : ce qui fonctionne, dans l'ordre

Les quatre couches ci-dessous s'empilent, et l'ordre compte. Les deux premières suppriment le rendement de l'attaque ; les deux suivantes en réduisent le débit et en révèlent la présence.

1. Retirer au mot de passe son pouvoir d'ouvrir seul

C'est la seule mesure qui neutralise la classe entière, et non ses symptômes : si un mot de passe valide ne suffit plus à ouvrir la session, une combo list ne vaut plus rien. Une nuance technique s'impose toutefois entre les seconds facteurs. Un code à usage unique par SMS ou par application se relaie en temps réel via une page de phishing intermédiaire, et il se contourne par lassitude quand l'utilisateur reçoit sa quinzième notification de la journée. Une passkey, elle, repose sur une paire de clés liée à l'origine du site : il n'existe aucun secret à réutiliser, donc aucune réutilisation possible. Le passage aux passkeys retire la surface sur laquelle le credential stuffing opère.

En pratique, la migration est progressive. Le piège est alors le compte laissé en arrière : les campagnes ciblent en priorité les identités sans second facteur, les comptes de service, et les parcours de secours (récupération par question secrète, connexion par ancien client mobile). Une voie de contournement laissée ouverte annule la politique qui la précède.

2. Refuser les mots de passe déjà fuités, sans jamais les transmettre

La révision 4 de NIST SP 800-63B est explicite : lors de la création ou du changement d'un mot de passe, le vérificateur doit comparer le secret candidat à une liste de mots de passe connus comme communs, attendus ou compromis, et refuser en expliquant le motif. Le texte formule cela comme une obligation, et c'est la seule contre-mesure qui attaque la matière première de l'attaquant.

Reste le comment : vérifier un mot de passe contre un corpus externe sans le lui envoyer. La réponse est la requête par intervalle, dite k-anonymity. On calcule l'empreinte du candidat, on n'envoie que ses cinq premiers caractères hexadécimaux, et le service renvoie tout le seau correspondant, quelques centaines de suffixes accompagnés de leur nombre d'occurrences. La comparaison finale se fait chez vous. Le mécanisme, ses garanties et ses limites sont détaillés dans notre avis sur Have I Been Pwned.

# Vérification par k-anonymity, côté serveur, à l'inscription ET à la connexion.
# Le mot de passe candidat ne quitte jamais votre infrastructure.

PW='correct horse battery staple'
FULL=$(printf '%s' "$PW" | sha1sum | cut -d' ' -f1 | tr 'a-f' 'A-F')

PREFIX=${FULL:0:5}     # les 5 premiers caractères hex : c'est TOUT ce qui sort
SUFFIX=${FULL:5}       # le reste ne sort jamais

# le service renvoie ~800 suffixes commençant par ce préfixe, sans savoir lequel vous cherchez
curl -s "https://api.pwnedpasswords.com/range/$PREFIX" | grep -i "^$SUFFIX:" \
  && echo "mot de passe présent dans un corpus de fuites -> refuser / forcer la rotation"

3. Découpler les messages d'erreur pour ne rien énumérer

Une campagne de stuffing commence souvent par un tri : séparer, dans une combo list de cinq millions de lignes, les adresses qui correspondent à un compte chez vous des autres. Si votre application répond "cette adresse est inconnue" d'un côté et "mot de passe incorrect" de l'autre, vous venez d'offrir ce tri gratuitement, et de réduire d'autant le volume que l'attaquant devra vous envoyer ensuite.

Le découplage doit être total, et c'est là que ça se complique : un message identique ne suffit pas si le temps de réponse diffère. Un compte inexistant qui répond en 8 ms quand un mot de passe faux répond en 250 ms (le temps de vérifier une empreinte argon2) est aussi bavard qu'un message explicite. La parade tient en une ligne : exécuter la vérification même quand le compte n'existe pas, contre une empreinte factice calibrée avec les mêmes paramètres de coût.

# Chemin d'authentification indistinguable, quel que soit l'état du compte.
# DUMMY_HASH est une empreinte factice générée avec les MÊMES paramètres de coût
# que les empreintes de production, sinon le temps de réponse trahit l'absence.

user   = users.find_by_email(email)
stored = user.password_hash if user else DUMMY_HASH

ok = verify(password, stored)          # toujours exécuté : coût constant

if not (user and ok):
    audit.record("login_failed", email=email, request=request)   # on trace...
    return response(401, "Identifiant ou mot de passe incorrect") # ...on ne révèle rien

# Les mêmes règles s'appliquent AUSSI à :
#   - la réinitialisation de mot de passe ("si un compte existe, un e-mail a été envoyé")
#   - le formulaire d'inscription (le classique "cette adresse est déjà utilisée")
#   - l'étape MFA : ne jamais la présenter uniquement quand le mot de passe est bon,
#     sinon l'écran de second facteur devient l'oracle de validité.

Ce dernier commentaire vise le piège le plus fréquent, qu'on rencontre sur des applications par ailleurs très propres : l'écran de saisie du code à usage unique n'apparaît que lorsque le mot de passe est correct. Le second facteur protège alors la session, mais confirme la validité du couple, soit l'information même que la campagne cherche à produire.

4. Détecter sur la forme du trafic, pas sur son volume

Puisqu'une requête de stuffing est indiscernable d'une connexion légitime prise isolément, la détection ne peut vivre qu'au niveau de l'agrégat. Le signal le plus robuste, et le moins coûteux à mettre en place, n'est pas le nombre de tentatives : c'est l'effondrement du taux de succès. Un endpoint d'authentification sain présente un ratio de succès stable, propre à chaque application, qu'il faut donc mesurer chez soi avant de pouvoir s'en servir comme référence. Une campagne qui rejoue une combo list largement périmée fait plonger ce ratio bien avant que le volume total ne déclenche la moindre alerte de charge.

-- Le signal, ce n'est pas le volume : c'est le ratio, et la dispersion.
-- Une campagne fait chuter le taux de succès tout en explosant le nombre
-- de comptes distincts touchés par IP, alors que la charge, elle, reste banale.

SELECT date_trunc('minute', ts)                                        AS minute,
       count(*)                                                        AS tentatives,
       round(100.0 * count(*) FILTER (WHERE outcome = 'success')
                   / nullif(count(*), 0), 1)                           AS taux_succes_pct,
       count(DISTINCT account_id)                                      AS comptes_distincts,
       count(DISTINCT src_ip)                                          AS ip_distinctes,
       round(count(DISTINCT account_id)::numeric
                   / nullif(count(DISTINCT src_ip), 0), 2)             AS comptes_par_ip
FROM auth_attempts
WHERE ts > now() - interval '6 hours'
GROUP BY 1
ORDER BY 1;

-- Lecture : taux_succes_pct qui passe de 90 à 4 avec comptes_par_ip proche de 1,
-- c'est la signature d'un pool de proxys qui rejoue une liste. Un brute force
-- classique produit exactement l'inverse : peu de comptes, beaucoup d'IP par compte.

Au-dessus de cette mesure viennent les empreintes comportementales et client : ordre et casse des en-têtes HTTP/2, empreinte de la négociation TLS, cohérence entre l'en-tête User-Agent annoncé et les capacités observées, chargement ou non des ressources secondaires de la page, régularité surhumaine des intervalles entre soumissions. Ces signaux fonctionnent et méritent d'être exploités, mais c'est une course : les frameworks d'automatisation modernes pilotent de vrais navigateurs et reproduisent des empreintes plausibles. L'empreinte achète du temps et augmente le coût de l'attaquant. C'est pourquoi les couches 1 et 2, qui retirent la valeur de l'attaque, passent devant.

Le volet conformité : ce que la loi attend avant l'incident

Deux obligations distinctes se croisent ici, et on les confond souvent. La première est permanente : l'article 32 du RGPD impose des mesures de sécurité appropriées au risque, et le credential stuffing est aujourd'hui un risque documenté, chiffré, publiquement connu. Il devient donc très difficile de plaider l'imprévisibilité, surtout quand vos propres notifications d'incident attestent que vous saviez.

La seconde se déclenche à l'incident. Des comptes clients pris, ce sont des données personnelles accessibles à un tiers non autorisé, donc une violation au sens de l'article 4 (12). Ce qui suit, du moment exact où démarre le compte à rebours de 72 heures jusqu'à ce qu'il faut consigner même quand on décide de ne pas notifier, est traité dans notre article dédié aux fuites de données et à la conduite à tenir en 72 heures.

Une dépendance opérationnelle mérite d'être anticipée : distinguer après coup les comptes pris de la masse des tentatives échouées suppose d'avoir conservé des journaux d'authentification exploitables, avec l'issue de chaque tentative et un identifiant de session. Sans cela, l'analyse d'impact devient une conjecture, et une conjecture ne se notifie pas proprement.

Le versant amont : savoir ce qui a déjà fuité chez vous

Toutes ces défenses attendent l'attaque au guichet. Il existe un versant amont, moins pratiqué et pourtant plus confortable, qui consiste à connaître avant l'attaquant le contenu des listes qui vous concernent. Savoir que 340 adresses de votre domaine figurent dans des fuites récentes, dont onze comptes à privilèges, change la nature de la conversation : on ne discute plus d'un risque abstrait, on traite une liste nominative.

À l'échelle individuelle, cette vérification tient dans les gestes décrits dans notre article sur les mots de passe compromis et l'ordre dans lequel les traiter. À l'échelle d'une organisation, elle demande une surveillance continue, rattachée aux bons actifs : c'est ce que fait le module Leaks & secrets de détection des identifiants exposés de notre plateforme EASM, qui part de votre domaine, remonte les identifiants et secrets qui s'y rattachent dans les corpus de fuites, et alerte quand un nouveau lot vous concerne.

Questions fréquentes sur le credential stuffing

À retenir

• Le credential stuffing vérifie, il ne devine pas. OWASP le sépare formellement du brute force (OAT-007) pour cette raison. Les mots de passe testés sont réels et proviennent de la fuite d'un tiers, à raison d'un essai par compte : aucun verrouillage n'est approché, aucune rafale n'apparaît dans vos journaux.
• Ce qui est sanctionné, c'est la réutilisation, pas la faiblesse. Une phrase de passe de quarante caractères tombe si elle a servi ailleurs. Le DBIR 2025 mesure une médiane de 49 % de mots de passe distincts par utilisateur : c'est le plafond de rendement de l'attaque, et il n'a rien à voir avec votre politique de complexité.
• Le compteur par IP a perdu sa corrélation avec l'intention. Un million de tentatives réparties sur 100 000 proxys résidentiels, c'est dix essais par adresse. Le seuil qui attraperait ça bloquerait d'abord vos clients derrière un NAT d'entreprise ou un CGNAT d'opérateur.
• Deux couches suppriment le rendement (passkeys ou MFA résistante au phishing, filtrage des mots de passe déjà fuités par requête k-anonymity, à l'inscription et à la connexion) et deux le révèlent (réponses indistinguables jusqu'au temps de réponse, détection sur l'effondrement du taux de succès plutôt que sur le volume).
• L'écran MFA ne doit pas devenir l'oracle. S'il n'apparaît que lorsque le mot de passe est bon, il confirme l'information même que la campagne cherche à produire.
• Le juge regarde le délai de réaction. La CNIL a sanctionné en janvier 2021 sur l'article 32 non pas l'attaque, mais l'année écoulée avant le déploiement d'un outil de détection, alors que les notifications d'incident s'accumulaient.

Reste à passer du principe au cas particulier. Les identifiants de votre domaine qui circulent déjà dans ces listes, le module Leaks & secrets de notre EASM les remonte en continu. Le comportement de vos parcours d'authentification, lui, se constate en les attaquant : énumération, oracle MFA, endpoints legacy oubliés, ratios de succès sous charge. C'est un pentest web blackbox, et la page contact en fixe le périmètre.