Le credential stuffing ne casse rien : il rejoue des couples identifiant/mot de passe issus de fuites, en pariant sur la réutilisation. Toute la mécanique repose sur une hypothèse discrète mais indispensable : l'identifiant est le même d'un service à l'autre. C'est une clé de jointure. Une approche IDless, sans identifiant permanent, retire cette clé — et donc l'étape sans laquelle l'attaque n'a pas de point de départ.
L'anatomie d'une campagne
| Étape | Ce que fait l'attaquant | Ce qui la rend possible | Ce que change l'IDless |
|---|---|---|---|
| Acquisition | achète ou récupère des lots de fuites | des bases exploitables circulent | sans effet direct |
| Jointure | rapproche les identifiants de votre service | l'adresse e-mail sert de clé universelle | il n'y a pas de clé à rapprocher |
| Test | rejoue les couples à grande échelle | l'authentification accepte un couple statique | rien de statique n'est accepté |
| Filtrage | isole les comptes qui répondent | messages d'erreur différenciés | pas d'énumération possible |
| Exploitation | fraude, revente, latéralisation | le compte donne accès directement | l'action sensible exige une validation propre |
La deuxième ligne est le pivot. Le taux de réussite d'une campagne est faible, mais son coût unitaire est presque nul : c'est un jeu de volume. Retirer la jointure ne réduit pas le taux de réussite, elle supprime la possibilité même de tenter.
Pourquoi les contre-mesures classiques fatiguent
Les réponses habituelles fonctionnent, jusqu'à un certain point.
- La limitation de débit est contournée par la distribution : proxys résidentiels, botnets, cadence lente. Une campagne étalée sur des semaines ne déclenche aucun seuil.
- Le blocage d'adresses IP perd en efficacité pour la même raison, et produit des faux positifs coûteux.
- La détection de mots de passe compromis ne protège que si l'utilisateur change effectivement, et arrive souvent après la fuite.
- La MFA casse l'exploitation directe, ce qui est décisif — mais elle transforme le problème en attaque d'approbation ou en ingénierie sociale du parcours de récupération.
Aucune de ces mesures ne s'attaque à la matière première. Elles rendent la campagne moins efficace ; elles ne la rendent pas impossible.
IDless : ce que signifie « pas d'identifiant permanent »
L'approche IDless consiste à ne pas faire reposer l'authentification sur un identifiant durable saisi par l'utilisateur. Combinée au passwordless, elle produit un effet simple : il n'existe ni identifiant ni mot de passe à rejouer.
Le parcours repose alors sur trois éléments : un QR code dynamique à usage unique qui ouvre un canal éphémère chiffré, un challenge résolu par la méthode personnelle de l'utilisateur, et une exécution protégée par des mécanismes de Moving Target Defense. Ce qui circule ne vaut que pour l'échange en cours.
Trois conséquences sur le credential stuffing :
- Aucune jointure possible entre une base de fuites et vos comptes.
- Aucune énumération : impossible de constituer la liste des comptes valides, ce qui coupe aussi le password spraying.
- Aucune valeur produite en cas de succès partiel : il n'y a rien à revendre pour la campagne suivante.
L'objection sérieuse : et l'identification, alors ?
Un service doit bien savoir à quel compte rattacher une session. La distinction utile est celle entre identification et authentification.
L'identification n'a pas besoin d'un identifiant public, saisi par l'utilisateur dans un formulaire exposé et réutilisé partout. Elle peut reposer sur la mise en relation entre une session ouverte et un terminal enrôlé. Ce qui disparaît, c'est le champ « identifiant » — c'est-à-dire précisément l'élément qui sert de clé de jointure à l'attaquant et de point de départ au ciblage.
Ce qui subsiste : votre annuaire interne, vos droits, votre gouvernance des comptes. L'IDless ne supprime pas la notion de compte, il supprime le secret partagé qui l'ouvre.
Ce qu'il reste à traiter
- Les parcours de récupération, qui reposent souvent sur une adresse e-mail — laquelle redevient une clé de jointure si l'on n'y prend garde.
- Les comptes de service et les interfaces techniques, généralement authentifiés par des secrets statiques et rarement inclus dans les projets d'authentification.
- Les applications tierces qui conservent leur propre couple identifiant/mot de passe hors du périmètre du SSO.
FAQ
La MFA ne suffit-elle pas contre le credential stuffing ?
Elle bloque l'exploitation directe, ce qui est déjà beaucoup. Mais elle laisse l'attaquant en possession d'identifiants valides, qu'il exploitera par MFA fatigue, par ingénierie sociale du support, ou via un parcours de récupération plus faible.
Comment savoir si nous sommes visés ?
Les signaux utiles sont un pic de tentatives échouées réparties sur de nombreux comptes, un taux anormal d'échecs sur des comptes inexistants, et des connexions réussies depuis des plages d'hébergement plutôt que depuis des réseaux d'utilisateurs.
Que faire des comptes déjà exposés dans des fuites ?
Traiter d'abord les comptes à privilèges et les comptes disposant d'un pouvoir financier, en supprimant le secret réutilisable plutôt qu'en le remplaçant par un autre secret réutilisable.
L'IDless est-il compatible avec un SSO existant ?
Le facteur peut se déployer en overlay d'une chaîne existante, ce qui permet de commencer par les parcours les plus exposés sans refondre l'IdP.
Aller plus loin : le 4ᵉ facteur cognitif · l'IDless face au spear phishing · le score de risque face au credential stuffing · l'authentification sans identifiant