Credential stuffing : définition et protection

Qu’est-ce que le credential stuffing ?

Le credential stuffing est une attaque dans laquelle des bots prennent des paires identifiant et mot de passe divulguées par un site web et les essaient sur le formulaire de connexion d’un autre. Elle fonctionne parce que les gens réutilisent leurs mots de passe. Quiconque a utilisé la même adresse e-mail et le même mot de passe sur une boutique en ligne piratée et sur votre service a remis à l’attaquant un identifiant valide pour votre service.

Vous verrez aussi l’orthographe « credentials stuffing », et parfois la traduction « bourrage d’identifiants ». Il s’agit de la même attaque, et le nom la décrit bien : des identifiants volés sont « bourrés » dans le formulaire de connexion d’un autre site, à la vitesse d’un bot, jusqu’à ce que certains fonctionnent.

L’attaquant ne devine rien. Chaque paire de la liste a appartenu à un vrai compte quelque part. La plupart échouent sur votre site, parce que la personne n’a jamais eu de compte chez vous ou a choisi un autre mot de passe. Cela gêne à peine l’attaquant. Les listes sont longues, les tentatives ne coûtent presque rien, et une petite part de réussites suffit à rentabiliser l’opération.

L’intérêt des comptes qui fonctionnent dépend de votre activité : moyens de paiement enregistrés, points de fidélité et soldes de cartes cadeaux, données personnelles pour le phishing, ou simplement des comptes à revendre. Sur un produit SaaS, un seul compte compromis peut exposer tout l’espace de travail d’un client. Le credential stuffing est la voie automatisée vers la prise de contrôle de compte, et notre page sur la protection contre la prise de contrôle de compte présente l’ensemble des mesures.

Comment se déroule une attaque par credential stuffing

Une attaque par credential stuffing comporte quatre étapes, et une seule se passe chez vous.

1. Une liste divulguée. Des adresses e-mail ou des noms d’utilisateur avec leurs mots de passe, issus de fuites de données, de pages de phishing et de logiciels malveillants qui volent les mots de passe enregistrés dans les navigateurs. Ils circulent sous forme de « listes combo », souvent fusionnées à partir de nombreuses fuites, vendues ou partagées gratuitement.
2. Un outil configuré pour votre site. L’attaquant charge la liste dans un outil d’automatisation et ajoute une configuration pour votre connexion : quelle URL appeler, quels champs remplir, à quoi ressemble une connexion réussie. Les configurations pour les sites connus s’échangent comme les listes elles-mêmes.
3. Des bots répartissent les tentatives. L’outil envoie les connexions via de grands réseaux de proxys, souvent des adresses IP résidentielles, de sorte que chaque adresse n’envoie que quelques requêtes et que chaque compte n’est essayé qu’une ou deux fois. Pour votre serveur, cela ressemble à de nombreux visiteurs sans lien entre eux qui se sont chacun trompés une fois de mot de passe.
4. Les réussites deviennent des prises de contrôle. Les identifiants qui fonctionnent sont enregistrés, évalués selon leur valeur, puis utilisés, revendus ou verrouillés : l’attaquant change l’adresse e-mail et le mot de passe avant que le titulaire ne s’en aperçoive.

Vous ne pouvez pas récupérer une liste divulguée, et vous ne décidez pas où vos utilisateurs réutilisent leurs mots de passe. C’est à l’étape trois que vous avez votre mot à dire. Chaque paire de la liste doit passer par votre formulaire ou votre API de connexion, et c’est là que vous pouvez rendre chaque tentative coûteuse.

Credential stuffing ou force brute

Dans une attaque par force brute, l’attaquant ne connaît pas le mot de passe et le devine, généralement avec de nombreux mots de passe sur un même compte. Avec le credential stuffing, l’attaquant détient déjà un mot de passe que quelqu’un a réellement utilisé et l’essaie une fois sur le compte correspondant. Cette différence détermine quelles défenses fonctionnent.

Le verrouillage de compte est la réponse classique à la force brute : après un certain nombre d’échecs, le compte est bloqué ou ralenti. Contre le credential stuffing, il ne sert presque à rien, car chaque compte ne voit qu’une ou deux tentatives. La directive sur les mots de passe SP 800-63B de l’institut américain de normalisation NIST demande de limiter à 100 au plus les échecs consécutifs sur un même compte. Une campagne de credential stuffing n’approche ce chiffre sur aucun compte.

Le password spraying se situe entre les deux : une poignée de mots de passe courants essayés sur de nombreux comptes. L’OWASP Credential Stuffing Prevention Cheat Sheet traite les trois comme des attaques apparentées et note que la plupart des défenses agissent contre les trois.

Pour les attaques par devinette, notre guide sur la protection contre la force brute explique les verrouillages, les délais et la place d’un CAPTCHA.

Repérer le credential stuffing

Une campagne répartie sur des milliers d’adresses IP déclenche rarement une alerte isolée. Elle se voit dans les totaux :

• Les échecs de connexion augmentent sur de nombreux comptes à la fois, alors que le nombre par compte reste faible.
• Une part élevée des tentatives utilise des adresses e-mail qui n’ont aucun compte chez vous. Les vrais utilisateurs saisissent rarement une adresse que vous n’avez jamais vue.
• Les connexions viennent de réseaux que vous voyez rarement : hébergeurs, services de proxy, pays où vous n’avez pas de clients.
• Une adresse IP ou une empreinte d’appareil essaie de nombreux comptes différents, ou les requêtes arrivent à des intervalles étrangement réguliers.
• Les requêtes sautent des parties d’une visite normale : aucune ressource de page chargée, en-têtes manquants, traces d’un navigateur headless, appels directs à l’API de connexion.
• Ensuite : une vague de réinitialisations de mot de passe, d’adresses e-mail modifiées et de tickets de support sur des commandes que personne n’a passées.

Comment empêcher le credential stuffing

Aucune mesure isolée n’arrête le credential stuffing. Quatre mesures ensemble font l’essentiel du travail : l’authentification multifacteur, pour qu’un mot de passe volé ne suffise pas ; le contrôle des mots de passe divulgués, pour que les mots de passe des listes des attaquants ne fonctionnent plus ; des limites de débit qui vont au-delà de l’adresse IP ; et une détection de bots sur le formulaire de connexion, pour que chaque tentative automatisée ait un coût. Le cheat sheet OWASP cité plus haut décrit ces mêmes briques plus en détail.

Authentification multifacteur

L’OWASP qualifie la MFA de « by far the best defense against the majority of password-related attacks », de loin la meilleure défense contre la plupart des attaques sur les mots de passe, et cite une analyse de Microsoft selon laquelle elle aurait empêché 99,9 % des compromissions de comptes. Avec un second facteur, un mot de passe correct tiré d’une liste divulguée n’ouvre plus le compte.

La MFA a pourtant des failles. Elle ne protège que les comptes sur lesquels elle est activée, et sur les sites grand public, beaucoup d’utilisateurs ne l’activent jamais. Dans la plupart des parcours de connexion, l’étape du mot de passe réussit avant que le second facteur ne soit demandé. L’attaquant apprend donc toujours quels mots de passe sont valides, et cette information lui sert pour le phishing ou pour une avalanche de notifications push jusqu’à ce qu’un utilisateur fatigué accepte. Et chaque tentative atteint toujours vos serveurs. Une voie intermédiaire est la MFA basée sur le risque : vous demandez le second facteur quand une connexion semble inhabituelle, depuis un nouvel appareil, un nouveau pays ou avec un score de bot élevé.

Des limites de débit qui vont au-delà de l’adresse IP

Une limite par adresse IP est le premier réflexe, et les attaquants l’anticipent : ils font tourner des réseaux de proxys pour que chaque adresse reste sous votre limite. Ajoutez des limites par compte, par empreinte d’appareil et par plage réseau, et surveillez le taux global d’échecs de connexion. Un saut soudain de ce taux est souvent le premier signe qu’une campagne a commencé. Ralentir les réponses après des échecs coûte peu à un vrai utilisateur et beaucoup de temps à l’opérateur des bots.

Contrôle des mots de passe divulgués

Vérifiez les nouveaux mots de passe à l’inscription et à chaque changement de mot de passe par rapport à une liste de mots de passe connus issus de fuites, et refusez ceux qui y figurent. NIST SP 800-63B en fait une exigence pour les services qui suivent la directive : les nouveaux mots de passe doivent être comparés à une liste de blocage qui inclut les mots de passe issus de fuites précédentes. Des services comme Pwned Passwords de Have I Been Pwned permettent ce contrôle sans envoyer le mot de passe nulle part. Vous envoyez seulement les premiers caractères de son empreinte (hash) et comparez les correspondances renvoyées sur votre propre serveur.

Le même contrôle fonctionne à la connexion. Si quelqu’un se connecte avec un mot de passe qui apparaît dans une fuite, demandez-lui de le changer avant qu’un attaquant ne le fasse.

Détection de bots sur le formulaire de connexion

Le credential stuffing vit du volume. Une détection de bots sur le formulaire de connexion, par un CAPTCHA, une tâche de preuve de travail ou des signaux d’appareil et de comportement, donne un prix à chaque tentative et signale celles qui semblent automatisées. Avec un score de bot, votre serveur peut traiter les connexions différemment : laisser passer celles qui sont propres, demander un second facteur aux douteuses et rejeter les bots évidents.

Validez le résultat sur le serveur pour chaque requête de connexion, et couvrez chaque accès : le formulaire web, l’API de votre application mobile, les anciens points de connexion, le formulaire de réinitialisation du mot de passe et toute étape qui révèle si une adresse e-mail a un compte. Les attaquants cherchent l’unique entrée sans contrôle.

Un CAPTCHA peut-il arrêter le credential stuffing ?

Un CAPTCHA aide contre le credential stuffing, et c’est vrai quel que soit le fournisseur : hCaptcha, Google reCAPTCHA, Cloudflare Turnstile et TrustCaptcha rendent tous les tentatives de connexion automatisées plus lentes et plus coûteuses. Aucun n’arrête l’attaque à lui seul. L’OWASP rappelle que les CAPTCHA « are not perfect », qu’ils ne sont pas parfaits, et qu’il existe des outils et des services qui les cassent avec un taux de réussite assez élevé. Une connexion qui passe le CAPTCHA fonctionne quand même si le mot de passe est bon.

Voyez donc le CAPTCHA comme la couche qui réduit le volume, et comptez sur la MFA et le contrôle des mots de passe divulgués pour les tentatives qui passent. Pour les formulaires de connexion, les différences entre fournisseurs qui comptent le plus sont de savoir si vos utilisateurs voient un défi, si vous obtenez un score exploitable et où les données des visiteurs sont traitées. Le même CAPTCHA sur vos formulaires de contact et d’inscription réduit aussi le spam automatisé, et à l’inscription il aide à empêcher la création de faux comptes par le même type d’automatisation.

De petites mesures qui s’additionnent

• Affichez le même message d’erreur pour un mauvais identifiant et un mauvais mot de passe, pour que votre page de connexion n’indique pas aux attaquants quelles adresses e-mail ont un compte.
• Prévenez les utilisateurs des connexions depuis un nouvel appareil. Ils repèrent souvent une prise de contrôle avant votre surveillance.
• Permettez aux utilisateurs de voir et de fermer leurs sessions actives.
• Proposez les passkeys. Un compte qui se connecte avec une passkey n’a pas de mot de passe qui puisse fuiter et être réutilisé.

Que faire pendant une attaque

1. Relevez la barrière à la connexion : augmentez la difficulté de la preuve de travail, exigez la vérification anti-bot à chaque connexion et bloquez les réseaux d’où vient l’attaque.
2. Identifiez les comptes avec des connexions réussies depuis les adresses IP ou les appareils de l’attaque, fermez leurs sessions et imposez un nouveau mot de passe.
3. Expliquez aux utilisateurs concernés ce qui s’est passé et ce qu’ils doivent faire, y compris changer le mot de passe sur les autres sites où ils l’ont utilisé.
4. Vérifiez si des données personnelles ont été consultées, et demandez à votre délégué à la protection des données si l’incident doit être notifié.
5. Une fois l’attaque terminée, vérifiez quel point de connexion elle a utilisé et comblez cette faille.

TrustCaptcha sur votre formulaire de connexion

TrustCaptcha vérifie chaque connexion en arrière-plan. Le widget démarre tout seul et résout une tâche de preuve de travail dans le navigateur : un vrai utilisateur n’a rien à résoudre ni à cliquer, tandis qu’un bot paie pour chaque tentative. La preuve de travail se durcit à mesure que le risque d’une requête augmente, ce qui rend coûteuse une campagne de milliers de connexions venant d’un trafic suspect.

À partir de l’offre Solo, un score de bot et des règles de preuve de travail personnalisées donnent à votre serveur un signal sur lequel agir : laisser passer la connexion, demander le second facteur ou la refuser. TrustCaptcha ne dépose aucun cookie, traite les données dans des centres de données situés dans l’UE et fournit un accord de traitement des données (DPA) à chaque client. C’est une couche de la sécurité de votre connexion, et elle fonctionne le mieux à côté de la MFA et du contrôle des mots de passe divulgués.

Essayer TrustCaptcha

Chaque offre commence par un essai gratuit de 14 jours, et les sites non commerciaux peuvent utiliser TrustCaptcha gratuitement. Commencez votre essai gratuit et placez sur votre formulaire de connexion une vérification que vos utilisateurs n’ont jamais à résoudre.