Face au credential stuffing, le mot de passe ne protège que par une seule propriété : son unicité. C'est aussi la seule que l'organisation ne peut ni vérifier ni imposer, puisqu'elle dépend de ce que l'utilisateur fait sur des services tiers. L'attaque ne devine rien et ne casse rien : elle rejoue ailleurs des couples identifiant/mot de passe déjà valides. Longueur, complexité et rotation n'ont aucun effet sur elle.
Une attaque de logistique, pas de cryptographie
Le credential stuffing est un problème d'échelle. L'attaquant dispose de listes issues de fuites successives, souvent consolidées et nettoyées, et les rejoue automatiquement sur des services qui n'ont jamais été compromis. Le taux de succès par tentative est faible ; le volume compense.
Ce qui rend l'attaque difficile à contrer tient à sa normalité apparente. Chaque tentative réussie est une authentification correcte, avec un secret valide, souvent depuis une adresse résidentielle. Du point de vue du service, rien ne distingue l'attaquant de l'utilisateur légitime : il n'y a pas d'échec massif à détecter, pas de charge anormale sur un compte, pas de motif cryptographique suspect.
Les constats généraux du Verizon DBIR placent d'ailleurs les identifiants volés, réutilisés ou partagés parmi les tout premiers vecteurs d'intrusion. Le credential stuffing en est la traduction industrielle.
Ce que le mot de passe protège encore, et ce qu'il ne protège plus
| Propriété du mot de passe | Effet sur le credential stuffing | Commentaire |
|---|---|---|
| Longueur, complexité | Aucun | Le secret est connu, pas deviné |
| Rotation périodique | Marginal | Utile seulement si elle suit la fuite, ce qui est rare |
| Unicité par service | Décisif | Seule propriété réellement protectrice |
| Salage et hachage lent | Aucun côté cible | Protège la base, pas le rejeu ailleurs |
| Interdiction des secrets connus compromis | Réel | Traite le stock, pas la réutilisation future |
| Absence totale de mot de passe | Supprime l'attaque | L'attaque n'a plus d'objet |
La lecture de ce tableau est brutale mais utile : à l'exception de l'unicité, tout l'arsenal habituel de gestion des mots de passe est hors sujet. L'organisation dépense son énergie sur des mesures qui traitent une attaque différente.
L'angle mort : la compromission ne laisse pas de trace d'échec
La plupart des dispositifs de détection sont calibrés sur les échecs. Or ici, l'événement à repérer est un succès. Trois conséquences pratiques en découlent.
D'abord, la découverte est tardive : elle intervient au moment du préjudice — commande frauduleuse, exfiltration, changement de coordonnées bancaires — et non au moment de l'accès. Ensuite, la portée est difficile à établir : sans journalisation fine, il est impossible de dire depuis quand le compte est utilisé par un tiers. Enfin, la réponse habituelle, la réinitialisation du mot de passe, ne traite que le compte concerné, alors que la même paire reste valide sur d'autres services de l'entreprise et de la vie personnelle de l'utilisateur.
Il faut y ajouter un point rarement mentionné : le credential stuffing sert souvent de repérage. L'attaquant valide d'abord un lot d'identifiants, puis revend ou exploite sélectivement ceux qui donnent accès à des périmètres intéressants. Le délai entre la validation et l'exploitation peut se compter en semaines.
Les réponses qui agissent réellement
Trois familles de mesures ont un effet démontrable, par ordre croissant de portée.
Réduire la valeur du stock. Comparer les secrets aux corpus de mots de passe connus comme compromis, à l'enrôlement et au changement, empêche l'entrée de couples déjà rejoués. C'est peu coûteux et immédiatement utile, mais cela ne traite que ce qui est déjà public.
Ajouter du contexte à la décision. Puisque le secret est valide, le discriminant doit venir d'ailleurs : cohérence de l'appareil, du réseau, des horaires, de la séquence d'actions. Un score de risque contextuel permet alors de déclencher une vérification supplémentaire uniquement quand la situation le justifie, sans dégrader l'expérience de tous les utilisateurs.
Supprimer le secret réutilisable. C'est la seule réponse qui retire son objet à l'attaque. Une approche passwordless élimine la valeur rejouable ; une approche IDless, où aucune donnée identifiante n'est détenue centralement, réduit en outre l'intérêt d'une future fuite chez le fournisseur d'authentification lui-même. Le facteur cognitif « je sais faire » relève de cette logique : ce qui est vérifié est une intention humaine consciente au moment de l'action, et non un secret conservé quelque part.
FAQ
Le credential stuffing vise-t-il seulement les comptes clients ?
Non. Les portails clients sont les plus exposés en volume, mais les accès collaborateurs et les extranets partenaires sont visés en priorité pour leur valeur unitaire. La réutilisation entre un service personnel et un accès professionnel reste la faille la plus fréquente.
Un CAPTCHA règle-t-il le problème ?
Il augmente le coût de l'automatisation, sans plus. Les campagnes sérieuses le contournent, et il pénalise surtout les utilisateurs légitimes. Il peut servir de mesure d'appoint sur un pic, jamais de défense principale.
Faut-il forcer la réinitialisation de tous les mots de passe après une fuite tierce ?
Uniquement pour les comptes dont l'adresse figure dans la fuite, et en la couplant à une vérification de non-réutilisation. Une réinitialisation générale génère de la charge au service d'assistance et pousse les utilisateurs vers des variantes prévisibles de leur ancien secret.
La MFA suffit-elle à neutraliser le credential stuffing ?
Elle bloque l'exploitation directe, ce qui est déjà l'essentiel. Elle déplace toutefois l'attaque vers le second facteur : relais en temps réel pour un code, rafale d'approbations pour une notification. Le choix du second facteur détermine donc le gain réel.
Aller plus loin : authentification cognitive : le pilier · le mot de passe face au brute force · score de risque et credential stuffing · supprimer les mots de passe