La récupération de compte est le parcours où la plupart des déploiements de passkeys perdent le bénéfice qu'ils viennent d'acquérir. Un attaquant n'attaque pas la signature FIDO2 : il déclare que l'appareil est perdu et emprunte le chemin de secours. Le niveau de sécurité réel d'un compte est celui de son parcours de récupération le plus faible.
Pourquoi le problème est structurel
Une passkey n'est pas exportable et ne se « rappelle » pas. Quand l'authentificateur disparaît, il n'existe aucune manière cryptographique de reconstituer la clé privée. Le service doit donc, à un moment, décider de faire confiance à autre chose. C'est cette décision qui est attaquée.
Deux erreurs de conception reviennent systématiquement :
- Le repli implicite. Le parcours de secours n'a pas été conçu, il a été hérité : c'est celui qui existait avant la migration, en général un code envoyé par e-mail ou par SMS.
- L'asymétrie inversée. La récupération est plus rapide et moins exigeante que la connexion normale, alors qu'elle donne un pouvoir supérieur — celui de reconstituer l'accès.
Comparer les options de secours par leur plancher
| Option de récupération | Ce sur quoi elle repose | Plancher de sécurité obtenu |
|---|---|---|
| Second justificatif inscrit d'avance | possession d'un autre appareil enrôlé | équivalent à la connexion normale |
| Trousseau synchronisé du fournisseur | sécurité du compte de synchronisation | celui de ce compte, y compris son propre secours |
| Code de secours imprimé à l'enrôlement | conservation physique par l'utilisateur | bon si non stocké en clair, fragile en pratique |
| Code e-mail | contrôle de la boîte mail | celui de la messagerie, souvent inférieur |
| Code SMS | contrôle de la SIM | faible : SIM swapping, catégorie « restricted » au NIST SP 800-63B |
| Appel au support avec questions | mémoire de l'utilisateur, jugement de l'agent | faible : exposé au vishing et à la voix synthétique |
| Réenrôlement en présentiel | présence physique vérifiée | élevé, mais coûteux et lent |
| Preuve cognitive personnelle | capacité à résoudre un challenge appris | élevé, sans valeur transmissible ni objet à posséder |
La lecture de ce tableau donne la règle d'ingénierie : ne jamais accepter en récupération un facteur d'un niveau inférieur au facteur principal. Si cette règle rend la récupération trop coûteuse, ce n'est pas la règle qu'il faut assouplir, c'est la prévention qu'il faut renforcer en amont — c'est-à-dire l'inscription d'un second justificatif dès l'enrôlement.
Les quatre leviers de conception
Prévenir plutôt que récupérer. Chaque utilisateur disposant de deux justificatifs sur des supports distincts est un utilisateur qui n'appellera jamais le support. C'est le levier le plus rentable, et il ne coûte que quelques minutes à l'enrôlement.
Ralentir volontairement. Une récupération n'a pas besoin d'être instantanée. Un délai d'attente, associé à une notification sur tous les canaux enregistrés et à une possibilité d'annulation, transforme une attaque silencieuse en attaque visible. C'est l'une des rares mesures qui coûte peu et gêne réellement l'attaquant.
Contextualiser. Une demande de récupération émise depuis le pays et l'appareil habituels ne pose pas le même risque qu'une demande émise depuis un contexte inconnu, quelques minutes après une tentative de connexion échouée. Un score de risque contextuel permet de moduler l'exigence au lieu d'appliquer la même procédure à tout le monde.
Séparer les pouvoirs. Une récupération réussie devrait rendre l'accès, pas les privilèges. Une période pendant laquelle les opérations sensibles — virement, changement d'IBAN, ajout d'un justificatif, modification des coordonnées de contact — restent bloquées limite considérablement le gain d'une compromission.
Le cas particulier du support téléphonique
Quand la récupération passe par un agent humain, la surface d'attaque devient conversationnelle. Les informations demandées pour « vérifier » l'appelant — date de naissance, dernière facture, adresse — sont exactement celles qu'un attaquant collecte en amont. La synthèse vocale a par ailleurs rendu peu fiable l'identification à l'oreille.
Les organisations qui traitent ce risque sérieusement font converger trois mesures : une procédure écrite qui ne laisse pas de marge d'appréciation à l'agent, une vérification qui repose sur un élément que l'agent ne peut pas contourner, et une traçabilité complète des dérogations. Le principe consiste à retirer à l'agent le pouvoir de décider, plutôt qu'à le former à mieux décider.
C'est également l'apport d'une preuve d'intention humaine consciente : si la reprise d'accès suppose de résoudre un challenge appris hors ligne, ni la persuasion, ni une voix imitée, ni un document falsifié ne permettent d'y parvenir à la place de l'utilisateur.
FAQ
La synchronisation cloud règle-t-elle le problème de la récupération ?
Elle le déplace. Le trousseau restitue les justificatifs sur un nouvel appareil, ce qui supprime la plupart des appels au support. Mais le niveau de sécurité devient celui du compte de synchronisation et de son propre parcours de secours, qu'il faut donc évaluer.
Faut-il fournir des codes de secours à usage unique ?
Ils constituent un filet acceptable s'ils sont générés en une seule fois, affichés une seule fois et invalidés à l'usage. Leur faiblesse est humaine : ils finissent souvent dans un fichier ou une boîte mail, ce qui les ramène au niveau de la messagerie.
Quel délai imposer avant qu'une récupération soit effective ?
Il n'existe pas de valeur universelle : le délai se calibre sur l'impact d'un compte compromis et sur la tolérance métier à l'indisponibilité. Un délai différencié — court pour un compte de faible enjeu, plus long pour un compte à privilèges — est généralement plus défendable qu'une valeur unique.
Comment traiter la récupération pour les comptes d'administration ?
En excluant purement et simplement l'automatisation. Pour ces comptes, la reprise doit impliquer une vérification humaine renforcée, idéalement en présentiel ou par une procédure à double validation, avec journalisation intégrale.
Aller plus loin : pilier : authentification cognitive · sécuriser la connexion avec passkey · récupération de compte par OTP e-mail · reset au helpdesk : le risque social