Sur le parcours de connexion, la passkey est aujourd'hui la méthode la plus solide largement déployable : la signature produite est liée au domaine qui la demande, ce qui neutralise le relais par proxy inverse. En revanche, elle ne protège que l'instant de la connexion — ni la session qui suit, ni le parcours de secours qui la contourne.
Ce que la connexion par passkey change vraiment
Une connexion classique transmet une valeur que le serveur compare : mot de passe, code à usage unique, réponse à une question. Cette valeur peut toujours être captée puis rejouée par un intermédiaire. Une connexion FIDO2 ne transmet aucune valeur comparable : l'authentificateur signe un défi aléatoire, et cette signature n'a de sens que pour le domaine exact qui l'a demandée.
Conséquences directes sur votre carte des risques :
| Attaque sur la connexion | Effet de la passkey |
|---|---|
| Phishing par page contrefaite | la clé du domaine légitime ne se déclenche pas sur le faux domaine |
| Proxy inverse en temps réel (AiTM) | rien de rejouable ne circule vers l'attaquant |
| Credential stuffing | aucun secret partagé à rejouer ; les fuites tierces deviennent inopérantes |
| Fuite de la base d'authentification | seules des clés publiques sont exposées |
| Enregistreur de frappe | aucune saisie de secret à capter |
| Vol du jeton de session | non couvert — la session reste un porteur |
| Manipulation de l'utilisateur en cours de session | non couvert — la connexion est légitime |
Les deux dernières lignes méritent d'être posées noir sur blanc dans une note de risque : elles concentrent l'essentiel du risque résiduel après un déploiement réussi.
Les décisions à trancher avant le déploiement
-
Synchronisée ou liée à l'appareil. Une passkey synchronisée simplifie la vie de l'utilisateur et absorbe le changement de téléphone. Elle étend en contrepartie le périmètre de confiance au fournisseur de trousseau. Pour les populations à privilèges, la passkey liée au matériel reste le choix défendable ; pour les populations courantes, la synchronisation réduit fortement le coût de support.
-
Le nombre de justificatifs par utilisateur. Un seul justificatif crée une dépendance à un objet unique. La pratique raisonnable consiste à faire inscrire deux justificatifs dès l'enrôlement, sur des supports distincts. C'est la mesure la plus efficace pour éviter que le parcours de secours ne devienne la porte d'entrée.
-
Le sort du mot de passe. Tant que le mot de passe reste accepté en repli sur le même compte, la passkey n'a rien retiré à l'attaquant : il suffit de faire échouer la passkey pour retomber sur l'ancien parcours. Le retrait effectif du repli est ce qui transforme un pilote en gain de sécurité.
4. Le périmètre applicatif. Une passkey posée devant le fournisseur d'identité couvre les applications fédérées, pas celles qui gardent une authentification locale. L'inventaire des accès directs conditionne le bénéfice réel.
Ce qui reste ouvert après la connexion
Une fois la session ouverte, le navigateur détient un jeton. Ce jeton est un porteur : quiconque le détient est traité comme l'utilisateur. Les techniques de vol de jeton — logiciel malveillant d'exfiltration, extension hostile, poste partagé — contournent entièrement l'authentification, aussi robuste soit-elle.
Trois contre-mesures se combinent :
- Réduire la fenêtre : durées de vie courtes, révocation immédiate à la détection d'anomalie, invalidation à la déconnexion et au changement d'appareil.
- Lier la session au contexte : signaux d'appareil, cohérence réseau, détection de réutilisation d'un jeton depuis un contexte différent.
- Revalider sur l'action : demander une preuve fraîche au moment d'une opération sensible, plutôt que de faire confiance à une session ouverte trois heures plus tôt.
Cette troisième piste est celle qui déplace le plus le curseur, car elle change l'objet de la preuve : on ne valide plus « une session existe » mais « un humain veut faire ceci, maintenant ». C'est le domaine de l'authentification cognitive, qui ajoute un facteur « je sais faire » aux facteurs de possession et d'inhérence.
Séquencer un déploiement sans casser l'exploitation
| Phase | Contenu | Critère de sortie |
|---|---|---|
| Cadrage | inventaire des applications, des populations et des parcours de secours | liste des accès hors fédération |
| Pilote | population volontaire, double inscription, mot de passe maintenu en repli | taux d'inscription et volume de tickets mesurés |
| Extension | ouverture par vagues, communication ciblée, assistance renforcée | seuil d'adoption atteint par vague |
| Durcissement | retrait du repli mot de passe, réduction des durées de session | plus aucun repli faible sur le périmètre couvert |
| Actions sensibles | validation portant sur l'opération et non sur la session | opérations critiques couvertes par une preuve fraîche |
L'erreur classique consiste à s'arrêter à la phase d'extension. Le taux d'adoption paraît bon, mais le repli faible subsiste et le gain réel reste théorique.
FAQ
Que se passe-t-il si l'utilisateur perd son téléphone ?
Tout dépend de ce qui a été prévu avant. Avec un second justificatif inscrit, la reprise est immédiate. Sans second justificatif, le parcours de secours prend le relais — et c'est lui qui définit alors le niveau de sécurité réel du compte.
Peut-on imposer la passkey à tous les utilisateurs ?
C'est possible sur un périmètre maîtrisé, mais rarement souhaitable d'emblée. Les postes partagés, les environnements industriels sans appareil personnel et les populations externes exigent des alternatives explicitement décidées, sinon elles seront contournées.
La passkey suffit-elle pour une exigence d'authentification forte réglementaire ?
La DSP2 demande deux facteurs de catégories distinctes et, pour un paiement, un lien dynamique avec le montant et le bénéficiaire. Une passkey déverrouillée par biométrie mobilise deux catégories, mais le lien dynamique doit être traité séparément, au niveau de la transaction.
Faut-il conserver un TOTP en secours ?
Cela revient à conserver une méthode relayable derrière une méthode qui ne l'est pas. Si un secours non matériel est indispensable, mieux vaut qu'il porte sur une preuve non rejouable plutôt que sur un code saisissable sur n'importe quelle page.
Aller plus loin : pilier : authentification cognitive · passkey, FIDO2, WebAuthn : les termes · sécuriser la récupération de compte avec passkey · MFA résistant au phishing