Le credential stuffing consiste à rejouer des couples identifiant / mot de passe issus de fuites antérieures. Face au facteur cognitif, cette attaque devient sans objet : il n'y a ni mot de passe à rejouer, ni identifiant sur lequel l'essayer. Ce n'est pas une résistance obtenue par détection ou par filtrage — c'est une disparition de la cible. La question utile n'est donc pas « résiste-t-il ? » mais « que reste-t-il exposé pendant et après la transition ? ».
Ce que supprime le passwordless, ce qu'ajoute l'IDless
Deux niveaux se distinguent, et la nuance a des conséquences pratiques.
Le passwordless supprime le mot de passe. Une liste de couples devient inutilisable telle quelle, puisque la moitié de la valeur — le secret — n'a plus de point d'application.
L'IDless supprime aussi l'identifiant. C'est un pas de plus, et il ferme des portes que le passwordless laisse ouvertes. Sans identifiant exposé, un attaquant ne peut plus :
- énumérer les comptes existants pour nettoyer sa liste avant de tester, opération de qualification qui précède presque toujours une campagne ;
- corréler un compte avec les autres services où la même adresse est utilisée, ce qui alimente le spear phishing ;
- cibler une personne précise sur un service donné, faute de savoir si elle y possède un compte.
Le facteur cognitif est conçu selon cette double approche passwordless et IDless, ce qui retire au rejeu de fuites toute prise, y compris dans sa phase préparatoire.
Ce qui reste vrai malgré tout
L'honnêteté technique impose de délimiter le périmètre. Trois situations subsistent.
La coexistence avec l'ancien système. Pendant une migration, l'authentification historique reste souvent active — pour les navigateurs anciens, pour les intégrations tierces, pour une population non encore basculée. Tant qu'un chemin accepte un couple identifiant / mot de passe, le rejeu fonctionne sur ce chemin. C'est de loin le risque le plus fréquent.
Les accès non interactifs. Comptes de service, clés d'API, intégrations machine à machine : ils ne comportent pas d'utilisateur humain et ne relèvent donc pas du facteur cognitif. Ils exigent leur propre discipline — coffre à secrets, rotation, restriction d'origine.
Les services tiers rattachés. Un système peut être passwordless tout en conservant une dépendance à une adresse de messagerie pour la récupération. Si cette messagerie est protégée par un mot de passe rejouable, le maillon faible s'y trouve.
| Situation | Le rejeu de fuites fonctionne-t-il ? | Raison | Traitement |
|---|---|---|---|
| Parcours entièrement IDless | Non | Aucune cible à rejouer | — |
| Parcours passwordless avec identifiant visible | Non pour le rejeu, oui pour l'énumération | L'identifiant reste exploitable | Masquer l'existence des comptes |
| Ancien parcours maintenu en parallèle | Oui | Un mot de passe subsiste | Fermer le chemin, pas seulement le masquer |
| API ou intégration héritée | Oui | Authentification par secret | Coffre, rotation, restriction d'origine |
| Récupération par e-mail | Indirectement | Le maillon faible se déplace | Aligner la récupération |
| Compte de service | Oui | Pas d'utilisateur humain | Discipline dédiée aux comptes non humains |
Le point de vigilance de toute migration
La ligne la plus dangereuse du tableau est la troisième. Une organisation qui déploie un facteur moderne mais laisse l'ancien parcours actif « pour ne bloquer personne » n'a pas réduit son exposition au rejeu : elle a ajouté un dispositif, elle n'a rien retiré.
Une migration sérieuse comporte donc une étape que l'on repousse volontiers : la fermeture effective du parcours historique, avec une date, une communication et un traitement des cas résiduels. Tant que cette étape n'est pas franchie, le niveau de sécurité reste celui de l'ancien système.
Les effets induits, souvent sous-estimés
Trois bénéfices apparaissent au-delà de la disparition du rejeu.
La disparition du déni de service par verrouillage. Une campagne de stuffing sur un système classique peut bloquer massivement des comptes légitimes par accumulation d'échecs. Sans compte identifiable ni compteur d'échecs associé à un identifiant, ce levier disparaît.
La réduction de la charge de support. Les demandes de réinitialisation de mot de passe représentent une part importante des sollicitations du guichet informatique, et elles sont le terrain privilégié de l'ingénierie sociale. Les supprimer réduit à la fois un coût et une surface d'attaque.
La minimisation des données. Une architecture décentralisée où aucune donnée identifiante n'est détenue par l'éditeur, avec une biométrie traitée localement, réduit mécaniquement l'exposition en cas d'incident : il n'existe pas de base centrale de couples à faire fuir. C'est aussi une position plus confortable au regard du RGPD.
FAQ
Sans identifiant, comment le système sait-il qui se connecte ?
La reconnaissance passe par la résolution d'un défi propre à la sollicitation, dans un canal éphémère ouvert par QR code dynamique à usage unique, plutôt que par la déclaration préalable d'une identité suivie d'une vérification. La séquence est inversée.
Une passkey suffit-elle contre le credential stuffing ?
Oui pour le rejeu proprement dit, puisqu'il n'y a plus de mot de passe. L'identifiant reste toutefois généralement visible, ce qui laisse subsister l'énumération de comptes et le ciblage.
Quel est le premier périmètre à traiter ?
Les parcours où un compte compromis produit le préjudice le plus élevé : accès à privilèges, gestes à effet financier, extranets donnant accès à des portefeuilles de données. La migration complète peut suivre.
Comment gérer les intégrations qui exigent un mot de passe ?
Les traiter comme des comptes non humains : secrets longs et uniques dans un coffre, rotation automatisée, restriction stricte des origines autorisées, et surveillance des usages anormaux.
Aller plus loin : le pilier authentification cognitive · l'approche IDless contre le credential stuffing · authentification sans identifiant · le mot de passe face au credential stuffing