La passkey supprime l'objet même du phishing d'identifiants : il n'y a plus de secret que l'utilisateur puisse communiquer, même s'il le voulait. C'est un progrès de nature, pas de degré. Mais une campagne de phishing ne s'arrête pas devant une impossibilité technique : elle se redirige. Contre un déploiement FIDO2, elle cible désormais trois choses — l'enrôlement, le repli et le consentement.
Ce qui devient structurellement impossible
Le phishing classique repose sur une chaîne simple : convaincre, collecter, rejouer. La passkey brise le premier maillon et le dernier.
Il n'y a rien à collecter, puisque la clé privée ne quitte pas l'authentificateur. Et il n'y a rien à rejouer, puisque la signature produite est liée au défi émis par le service et à l'origine effectivement visitée. Une page relais, même parfaitement imitée, obtient une réponse qui ne vaut rien sur le service authentique.
L'implication opérationnelle mérite d'être formulée clairement : sur ce parcours, la sécurité ne dépend plus de la capacité de l'utilisateur à repérer un domaine trompeur. Un utilisateur trompé reste protégé. Aucune mesure fondée sur la sensibilisation n'offre cette garantie.
Les trois cibles de repli du phishing
L'enrôlement
C'est aujourd'hui le vecteur le plus intéressant pour un attaquant. Le message ne demande pas de se connecter, il invite à « enregistrer votre nouvel appareil » ou à « activer la connexion sans mot de passe ». Si l'attaquant parvient à faire enrôler son authentificateur sur le compte de la victime, il obtient un accès légitime, durable et résistant au phishing — retourné contre son propriétaire.
Le parcours de repli et de récupération
Presque aucun déploiement n'est exclusif dès le premier jour. Tant qu'un compte accepte un code par SMS, un lien magique ou un OTP par courriel en cas de problème, le niveau de sécurité effectif du compte est celui de cette méthode de secours. Le message de phishing n'a alors qu'à provoquer la situation qui la déclenche.
Le consentement applicatif
Le message ne demande ni identifiant ni facteur : il propose d'autoriser une application. La victime s'authentifie normalement, avec sa passkey, et accorde des droits durables à un tiers contrôlé par l'attaquant. L'authentification a fonctionné exactement comme prévu ; c'est l'autorisation qui a été détournée.
| Objectif de la campagne | Efficacité contre un compte protégé par passkey | Signal de détection utile |
|---|---|---|
| Collecte de mot de passe | Nulle sur ce parcours | Sans objet |
| Relais d'assertion en temps réel | Nulle | Échecs d'origine côté service |
| Enrôlement d'un authentificateur attaquant | Élevée si le parcours n'est pas protégé | Ajout de facteur peu après connexion |
| Déclenchement d'un repli SMS ou courriel | Élevée tant que le repli existe | Usage anormal du parcours de secours |
| Consentement à une application tierce | Élevée | Nouvelle autorisation avec droits étendus |
| Vol de session après authentification | Élevée | Contexte d'usage différent du contexte d'authentification |
Ce qu'il faut décider pour que la promesse tienne
Trois mesures conditionnent le bénéfice réel du déploiement.
Protéger l'enrôlement au moins autant que la connexion. L'ajout d'un authentificateur devrait exiger la présentation d'un authentificateur déjà enrôlé, ou une vérification hors bande, et déclencher systématiquement une notification à l'utilisateur. Un enrôlement possible depuis une simple session ouverte annule une grande partie du gain.
Fermer les parcours de secours rejouables, en commençant par les populations à privilèges. Le recouvrement doit s'appuyer sur un second authentificateur enrôlé à l'avance plutôt que sur un code envoyé par un canal faible — l'OTP par SMS ou par voix est d'ailleurs classé « restricted » par le NIST dans sa publication SP 800-63B, c'est-à-dire déconseillé.
Traiter les autorisations applicatives comme une surface d'attaque à part entière, avec une liste d'applications approuvées, une revue périodique et une alerte sur toute nouvelle autorisation disposant de droits étendus.
Ce que la passkey ne prétend pas faire
Une passkey authentifie une connexion. Elle ne dit rien de ce que l'utilisateur fait ensuite, ni de l'intention réelle derrière une opération donnée. Un poste compromis, une session volée ou un utilisateur manipulé par téléphone échappent à son périmètre.
C'est là que se situe l'apport d'une preuve d'intention. Le facteur cognitif « je sais faire » demande à l'utilisateur de démontrer une intention humaine consciente au moment de l'action sensible, et non à l'ouverture de la session. Les deux approches se complètent bien : la liaison à l'origine ferme la porte d'entrée, la preuve d'intention protège les gestes qui comptent.
FAQ
Un utilisateur peut-il être trompé au point de « donner » sa passkey ?
Il ne peut pas la transmettre : la clé privée reste dans l'authentificateur. Il peut en revanche être amené à en enregistrer une autre, contrôlée par l'attaquant, ou à valider un parcours de secours. L'ingénierie sociale se déplace vers ces étapes.
Le phishing par SMS reste-t-il un problème ?
Oui, tant qu'un canal SMS conserve un rôle dans un parcours d'authentification ou de récupération. S'il ne sert plus qu'à des notifications sans effet sur l'accès, son intérêt pour un attaquant s'effondre.
Faut-il conserver un mot de passe en parallèle des passkeys ?
Le conserver revient à maintenir ouverte la voie que l'on cherchait à fermer. Une trajectoire par étapes est raisonnable, mais l'objectif doit être explicitement la suppression du mot de passe sur les parcours concernés, pas la coexistence permanente.
Comment vérifier que le déploiement produit l'effet attendu ?
En mesurant l'usage des parcours de secours plutôt que le taux d'adoption des passkeys. Un fort taux d'adoption accompagné d'un recours régulier au repli faible signifie que le niveau de sécurité réel n'a pas progressé.
Aller plus loin : authentification cognitive : le pilier · MFA résistante au phishing · passkey et récupération de compte · enrôler une passkey correctement