
Passkeys : le compte reste vulnérable si la récupération accepte un mot de passe

Pour déployer des passkeys sans laisser une voie de secours moins sûre, commencez par recenser tous les moyens d’accéder au compte. Introduisez ensuite les passkeys, préparez un accès de secours et sécurisez la récupération avant de retirer le mot de passe. Si un mot de passe réinitialisé permet encore d’ouvrir une session, cette voie reste exposée au phishing.
Le déploiement peut être progressif, à condition de distinguer les comptes qui disposent simplement d’une passkey de ceux qui doivent effectivement l’utiliser. Le cadre de la FIDO Alliance recommande cette progression et traite la récupération comme une méthode d’authentification à part entière. Une passkey facultative améliore le parcours de connexion choisi par l’utilisateur ; elle ne protège pas à elle seule les autres accès au même compte.
Recenser toutes les voies d’accès
Établissez la liste des parcours capables de créer une session ou de donner le droit d’inscrire un nouvel authentificateur. Elle doit couvrir la création du compte, la connexion sur un appareil connu ou nouveau, le changement d’adresse électronique, la perte des appareils, l’intervention du support et la connexion par un fournisseur d’identité externe. Pour chaque parcours, consignez la preuve demandée et les droits obtenus après sa validation.
Cette distinction révèle les contournements possibles. Un code reçu par SMS ou un lien envoyé par courriel peut sembler limité au dépannage ; s’il permet ensuite d’ajouter une passkey, il devient aussi une voie d’inscription. De même, un fournisseur d’identité externe qui accepte un simple mot de passe peut rouvrir un compte dont la connexion directe exige une passkey. Classez chaque parcours selon ce qu’il autorise réellement, plutôt que selon le nom affiché sur son écran.
Sécuriser l’inscription et préparer un secours
Avant d’associer une première passkey à un compte existant, exigez une authentification adaptée à cette opération. Appliquez la même vigilance lorsqu’un utilisateur ajoute un autre authentificateur : l’ajout donne potentiellement un accès durable au compte. Si un mot de passe récupérable suffit pour l’autoriser, une personne qui obtient ce mot de passe peut tenter d’inscrire sa propre passkey.
Le mécanisme explique à la fois l’intérêt de la passkey et la limite du parcours d’inscription. L’analyse de Berladskyy et Aßmuth décrit la clé privée utilisée par l’authentificateur pour signer un défi et la clé publique conservée par le service pour vérifier la réponse. Elle examine aussi des attaques qui supposent la compromission de l’authentificateur ou de la chaîne de confiance du navigateur. La résistance au phishing de la connexion repose notamment sur la liaison au domaine du service ; elle ne s’étend pas automatiquement à une procédure distincte qui accepte un mot de passe.
Prévoyez un moyen de secours avant la perte de l’appareil principal. Selon la politique du service, il peut s’agir d’une passkey synchronisée disponible sur un autre appareil ou d’un authentificateur distinct. Faites confirmer à l’utilisateur que ce moyen fonctionne, sans attendre une panne pour découvrir qu’il n’y a pas accès. Une passkey synchronisée et une passkey liée à un appareil ne présentent pas les mêmes conditions de disponibilité après une perte ; expliquez celles que votre service prend en charge.
Rendez également les authentificateurs enregistrés visibles dans les paramètres du compte, avec un moyen de signaler un ajout inconnu. Cette possibilité aide l’utilisateur à repérer un changement après coup et donne au support un état précis lors d’une demande de récupération. Elle ne remplace pas le contrôle exigé au moment de l’inscription.
Définir la récupération avant d’imposer les passkeys
Écrivez le scénario de perte totale avant de rendre la passkey obligatoire. Déterminez quelles preuves permettent de retrouver l’accès, qui les vérifie et ce que la récupération autorise : ouvrir immédiatement une session, ou seulement inscrire un nouvel authentificateur après des contrôles supplémentaires. Incluez les exceptions accordées par le support, car une exception permanente peut devenir le parcours le plus facile à attaquer.
Pour les comptes censés résister au phishing, ne laissez pas « mot de passe oublié » rétablir discrètement un accès complet. Les critères de prévention complète de FIDO demandent de retirer les méthodes vulnérables au phishing de la création du compte, de la connexion et de la récupération. Le document envisage encore certaines voies alternatives, notamment des liens par courriel, avec des contrôles tels que la limitation des tentatives et la détection des abus ; il ne les assimile pas pour autant à une passkey.
Si le retour au mot de passe reste nécessaire pendant la migration, indiquez précisément quels comptes y ont accès et pour quelles opérations. Une mesure intermédiaire peut protéger certaines fonctions ou certains utilisateurs, mais elle ne doit pas faire croire que tous les chemins vers le compte ont la même résistance. Testez aussi le scénario complet de perte d’appareil avec les règles du support : la politique appliquée doit correspondre à celle prévue dans le produit.
Révoquer et mesurer ce qui reste du mot de passe
Permettez de retirer une passkey associée à un appareil perdu ou à un ajout suspect. Côté service, la révocation doit empêcher l’utilisation future de la clé publique correspondante ; examinez séparément les autres authentificateurs enregistrés et les sessions déjà ouvertes. Supprimer une passkey ne ferme pas, à elle seule, une session créée auparavant.
Suivez la migration par parcours plutôt que par seul nombre de passkeys créées. Mesurez les connexions par passkey et par mot de passe, les demandes de récupération, les ajouts d’authentificateurs et les échecs après perte d’appareil. Séparez les comptes où la passkey est facultative de ceux où elle est exigée : leurs résultats ne décrivent pas le même niveau de protection.
Enfin, mesurez le recul du mot de passe dans la récupération et dans les exceptions du support, pas uniquement sur l’écran de connexion. Une baisse de son usage habituel peut coexister avec une réinitialisation qui redonne accès au compte. C’est cette possibilité concrète qui doit guider la décision de conserver, de restreindre ou de supprimer chaque voie de secours.
À lire aussi :
Articles similaires


Chaîne YouTube piratée : une clé d’accès ne suffit pas sans plan de secours

Mot de passe WhatsApp : ne le confondez plus avec le code d’inscription

Un message sans fautes peut être du phishing : vérifiez plutôt le contexte

Chaîne YouTube piratée : récupérer Google avant de réparer les vidéos

EvilTokens neutralisé : 12 000 boîtes compromises et la fraude automatisée
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.