Contre le credential stuffing, la passkey ne se défend pas : elle supprime la cible. L'attaque consiste à rejouer des couples identifiant/mot de passe valides ailleurs ; s'il n'existe aucun secret partagé entre l'utilisateur et le service, il n'y a rien à rejouer. Le bénéfice est donc total sur le parcours concerné — et c'est précisément cette formulation qui doit retenir l'attention, car un compte comporte rarement un seul parcours.
Pourquoi l'attaque devient sans objet
Le credential stuffing repose sur une hypothèse : le même secret vaut sur plusieurs services. Deux propriétés de FIDO2 la détruisent.
D'abord, la clé privée ne quitte jamais l'authentificateur. Elle n'est ni transmise, ni stockée côté service, ni comparée à une valeur enregistrée. Une fuite chez un service tiers ne peut donc pas livrer de matériel réutilisable. Ensuite, chaque service reçoit une paire de clés distincte : même si un secret pouvait être extrait, il ne vaudrait que pour un seul domaine. La réutilisation, qui est le carburant de l'attaque, devient structurellement impossible.
Cette différence explique pourquoi le sujet ne se traite pas par des contre-mesures. Le filtrage des robots, les listes d'adresses malveillantes ou la limitation de débit servent à rendre une attaque coûteuse. Ici, il n'y a rien à rendre coûteux.
Les trois chemins qui restent ouverts
Une organisation qui déploie des passkeys n'élimine pas le credential stuffing de son paysage de risque tant que ces trois points subsistent.
Le mot de passe résiduel. Dans la quasi-totalité des déploiements, le mot de passe reste actif sur le compte pendant la phase de transition, souvent pendant des années. Le compte accepte alors deux chemins d'accès, et son niveau de sécurité effectif est celui du plus faible. L'attaquant ne tentera pas la passkey : il tentera l'autre porte.
La récupération de compte. Un parcours de recouvrement fondé sur un courriel ou un numéro de téléphone rétablit une dépendance à un compte tiers, lequel est, lui, protégé par un mot de passe susceptible d'avoir fuité. La chaîne se déplace, elle ne disparaît pas.
Le compte de synchronisation. Les passkeys synchronisées entre appareils dépendent d'un compte de plateforme. Ce compte devient un objectif de valeur : le compromettre par credential stuffing revient à atteindre indirectement tous les services qui en dépendent. Sa protection doit être au moins équivalente à celle des services qu'il ouvre.
| Chemin d'accès au compte | Exposé au credential stuffing ? | Traitement recommandé |
|---|---|---|
| Authentification par passkey | Non | Rien à faire, l'attaque est sans objet |
| Mot de passe conservé en parallèle | Oui | Désactiver après enrôlement d'un second authentificateur |
| Récupération par courriel ou SMS | Oui, indirectement | Remplacer par un authentificateur de secours |
| Compte de synchronisation de plateforme | Oui | Exiger une méthode résistante au phishing |
| Comptes de service et clés d'interface | Sans objet mais rejouables | Rotation, restriction d'origine, cloisonnement |
| Anciens comptes non migrés | Oui | Inventorier avant de déclarer la migration terminée |
Ce que cela implique pour la trajectoire de migration
L'erreur classique consiste à mesurer l'avancement au taux d'adoption des passkeys. C'est un indicateur trompeur : un compte disposant d'une passkey et d'un mot de passe actif n'a pas progressé du point de vue du credential stuffing. Le seul indicateur qui traduise une réduction du risque est le nombre de comptes pour lesquels plus aucun chemin rejouable n'existe.
Trois décisions découlent de ce constat :
- Planifier la désactivation du mot de passe dès la conception du projet, avec un critère objectif de bascule — typiquement l'enrôlement de deux authentificateurs — plutôt que de la renvoyer à une phase ultérieure indéfinie.
- Reconstruire le parcours de recouvrement avant la migration, et non après. C'est lui qui déterminera si la suppression du mot de passe est tenable.
- Inventorier les accès qui échappent au fournisseur d'identité : applications anciennes, extranets, comptes techniques. Ils concentrent le risque résiduel et sont systématiquement découverts trop tard.
Ce qu'ajoute une approche sans identifiant
Supprimer le mot de passe retire la valeur rejouable côté utilisateur. Une approche IDless va un cran plus loin : aucune donnée identifiante n'est détenue par le fournisseur d'authentification, ce qui réduit l'intérêt même d'une future fuite à ce niveau. Combinée à une architecture décentralisée et à une biométrie traitée localement, elle limite la constitution des bases qui alimentent, quelques années plus tard, les campagnes de rejeu.
Le facteur cognitif ajoute enfin un élément que ni le mot de passe ni la passkey ne fournissent : la vérification porte sur une intention humaine consciente au moment de l'action, et non sur la détention d'un objet ou d'un secret. Un score de risque contextuel permet de réserver cette vérification aux situations qui le justifient.
FAQ
Le credential stuffing disparaît-il vraiment avec les passkeys ?
Sur le parcours d'authentification par passkey, oui, faute d'objet. À l'échelle d'une organisation, il subsiste tant qu'un mot de passe, un parcours de secours ou une application ancienne accepte un secret rejouable.
Combien de temps faut-il conserver le mot de passe en parallèle ?
Le temps que l'utilisateur dispose d'un moyen de secours qui ne soit pas un secret rejouable, ce qui se compte en semaines et non en années. Au-delà, la coexistence n'est plus une transition, c'est un choix d'architecture.
Les comptes de service posent-ils le même problème ?
Ils utilisent des secrets rejouables par construction et ne peuvent pas porter de facteur humain. La réponse consiste à restreindre leur portée, à faire tourner les secrets, à limiter les origines autorisées et à surveiller leur usage plutôt qu'à chercher à leur appliquer une passkey.
Faut-il continuer à surveiller les fuites d'identifiants après migration ?
Oui, aussi longtemps que des mots de passe subsistent quelque part dans le périmètre, y compris chez les prestataires et sur les comptes de plateforme dont dépendent les passkeys synchronisées.
Aller plus loin : le pilier authentification cognitive · l'approche IDless contre le credential stuffing · mot de passe et credential stuffing · migrer vers le passwordless