Contre une attaque adversary-in-the-middle, la passkey tient sur le point précis où toutes les autres méthodes cèdent : le relais de l'authentification. La réponse cryptographique est calculée pour un domaine déterminé, donc inexploitable depuis le domaine du proxy. Ce que cela ne dit pas, c'est ce que l'opérateur du relais fait ensuite — et il a deux options, toutes deux efficaces.
Pourquoi le relais échoue techniquement
Le proxy inverse fonctionne parce qu'il transporte des valeurs. Un code à usage unique, un mot de passe, une approbation : tout cela est indifférent au domaine sur lequel il est saisi. WebAuthn supprime cette indifférence.
Lors d'une authentification, le navigateur transmet à l'authentificateur, en plus du défi, l'origine effectivement visitée. La signature produite couvre ces éléments. Le service qui vérifie compare donc l'origine attendue à celle qui a été signée. Sur une page relais hébergée ailleurs, la valeur ne correspond pas, et l'assertion est rejetée. L'attaquant ne peut pas non plus « corriger » l'origine : elle est fournie par le navigateur, pas par la page.
Point important pour un arbitrage de sécurité : cette protection ne repose pas sur la vigilance de l'utilisateur. Elle fonctionne même si celui-ci n'a rien remarqué, ce qui la distingue radicalement de toutes les mesures fondées sur la sensibilisation.
Ce que fait l'opérateur du relais quand la passkey résiste
L'échec du relais ne met pas fin à la campagne. Il en déplace l'objectif.
Première option : la rétrogradation. La page relais présente une erreur plausible — « votre clé n'est pas reconnue sur ce poste », « connexion à distance : utilisez une autre méthode » — et propose un parcours alternatif. Si le service accepte encore un code par SMS, un OTP par courriel ou une notification push comme méthode de repli, l'attaque redevient un simple relais de valeur. C'est de loin le scénario le plus fréquent, parce que presque aucun déploiement n'est exclusif dès le premier jour.
Seconde option : viser l'après. L'attaquant laisse l'utilisateur s'authentifier normalement sur le site légitime, puis s'attache à récupérer la session : cookie volé par un logiciel dérobeur, jeton capté par une extension malveillante, ou consentement abusif accordé à une application tierce. La passkey a parfaitement rempli son rôle, et l'accès est quand même obtenu.
| Étape de l'attaque | Résultat avec passkey | Ce qui reste exploitable |
|---|---|---|
| Capture du mot de passe | Sans objet, il n'y en a pas | Rien sur ce parcours |
| Relais de l'assertion | Échec : origine non conforme | Rien |
| Proposition d'un repli SMS ou OTP | Réussite si le repli existe | Tout le parcours |
| Vol du cookie après authentification | Réussite | Session complète |
| Enrôlement d'un facteur attaquant | Réussite si le parcours n'est pas protégé | Accès persistant |
| Consentement à une application tierce | Réussite | Jeton d'accès durable |
Les trois décisions qui déterminent le résultat réel
Le niveau de protection obtenu ne dépend pas de la technologie mais de trois choix de mise en œuvre.
Le sort du repli. Tant qu'un parcours dégradé rejouable subsiste sur un compte, le niveau de sécurité de ce compte est celui du parcours dégradé, pas celui de la passkey. La suppression du repli faible est la décision structurante ; tout le reste est secondaire.
La protection de l'enrôlement. Ajouter un authentificateur est une opération au moins aussi sensible que se connecter. Si elle est accessible depuis une session ordinaire, l'attaquant qui dispose d'une session volée enrôle sa propre passkey et devient un utilisateur légitime.
La durée de vie des sessions. Puisque le butin résiduel est un jeton, sa validité définit la fenêtre d'exploitation. Des sessions longues sur des périmètres d'administration annulent en pratique une partie du bénéfice.
Fermer l'écart qui subsiste
Deux compléments traitent le résidu que la liaison à l'origine ne couvre pas.
Le premier consiste à ramener le contrôle au niveau de l'opération : au lieu d'authentifier une session puis de faire confiance, on exige une validation explicite au moment de l'action sensible. Une session volée ne suffit alors plus à virer des fonds, modifier un référentiel ou créer un compte à privilèges.
Le second consiste à faire varier ce qui est observé. Le principe de Moving Target Defense rend une interception stable inutile : ce qui est capté n'est plus valide ensuite. Combiné à un canal éphémère chiffré ouvert par un QR code dynamique à usage unique, il ne laisse à un intermédiaire rien de durable à recueillir.
C'est l'apport du facteur cognitif en complément d'un déploiement FIDO2 : la passkey sécurise l'entrée, la preuve d'intention sécurise ce qui se passe une fois entré. Un déploiement en overlay permet d'ajouter cette seconde couche sur les seuls parcours critiques, sans remettre en cause l'existant.
FAQ
Une passkey peut-elle être relayée par un proxy inverse ?
Non, dès lors que la vérification de l'origine est correctement implémentée côté service. C'est la propriété centrale de WebAuthn. Les échecs constatés en production proviennent des parcours de repli et des parcours de récupération, pas du protocole lui-même.
Faut-il désactiver immédiatement toutes les méthodes de repli ?
Pas sans avoir traité la question du recouvrement, sinon les blocages de comptes rendront la mesure intenable. La démarche réaliste consiste à supprimer d'abord les replis rejouables sur les populations à privilèges, puis à généraliser en s'appuyant sur un second authentificateur enrôlé plutôt que sur un code envoyé.
Comment détecter une campagne AiTM malgré la passkey ?
En surveillant les signaux qui suivent l'authentification : divergence entre le contexte d'authentification et celui d'usage, sessions actives depuis des infrastructures d'hébergement, enrôlement d'un facteur juste après une connexion, ou consentement inhabituel accordé à une application tierce.
Les passkeys synchronisées changent-elles l'analyse ?
Elles conservent la liaison à l'origine, donc la résistance au relais. Elles déplacent en revanche une partie du risque vers le compte de synchronisation : sa compromission devient un objectif intéressant, et sa protection doit être au moins équivalente à celle des services qu'il ouvre.
Aller plus loin : le 4e facteur cognitif · l'AiTM expliqué · QR dynamique contre l'AiTM · passkey, FIDO2 et WebAuthn