Passkeys : ces failles d'implémentation qui ravivent de vieilles attaques

Le 23 juillet 2026, Dark Reading publie une enquête qui devrait faire réfléchir toute équipe ayant activé la connexion par passkey sur son site : le protocole WebAuthn tient ses promesses de résistance au phishing, mais certaines implémentations côté site web réintroduisent, par la petite porte, les attaques que les passkeys étaient censées enterrer avec les mots de passe.

Précision utile avant d'aller plus loin : le texte intégral de cette enquête n'était pas accessible dans son intégralité au moment de la rédaction de cet article. Nous nous appuyons donc sur l'angle annoncé par Dark Reading et sur les classes de vulnérabilités WebAuthn documentées publiquement par le W3C et la FIDO Alliance, sans reprendre de chiffre ou de citation que nous n'avons pas pu vérifier nous-mêmes.

Les passkeys en trois lignes, pour ceux qui découvrent le sujet

Une passkey remplace le couple identifiant et mot de passe par une paire de clés cryptographiques générée sur votre appareil (ordinateur, téléphone, clé de sécurité). La clé privée ne quitte jamais l'appareil, ou le trousseau chiffré qui la synchronise : le site ne reçoit qu'une preuve signée que vous possédez cette clé. Ce mécanisme repose sur deux standards complémentaires. WebAuthn, porté par le W3C, définit l'API utilisée par le navigateur. FIDO2 regroupe WebAuthn et le protocole CTAP2, qui dialogue avec l'authentificateur : Touch ID, Windows Hello, clé de sécurité USB, etc. Le point fort du duo : la clé est liée cryptographiquement au domaine (l'origin) du site qui l'a enregistrée, ce qui rend en théorie le phishing classique inopérant, un faux site ne pouvant pas obtenir la signature attendue.

Ce que pointe Dark Reading : le protocole tient, l'implémentation flanche

Le message de fond de cette enquête rejoint un constat que plusieurs chercheurs en sécurité répètent depuis que les passkeys se généralisent sur le web : en tant que spécification, WebAuthn est solide. Mais un site web n'est jamais qu'une implémentation de cette spécification, avec ses propres choix de configuration, ses flux de secours et son parcours d'inscription. C'est précisément là que de vieilles attaques (phishing, downgrade, réutilisation de session) retrouvent une prise.

Les pièges d'implémentation les plus fréquents

• Le repli silencieux vers mot de passe ou code OTP. Beaucoup de sites proposent la passkey en option, avec un lien "utiliser un autre moyen de connexion" toujours visible. Un attaquant qui mène une campagne de phishing n'a alors aucune raison de s'attaquer à la passkey : il lui suffit de pousser la victime vers le mot de passe ou l'OTP, qui restent, eux, parfaitement phishables. La passkey cohabite avec la faille qu'elle devait combler, elle ne la ferme pas.
• Le paramètre userVerification laissé sur "preferred". Ce réglage de l'API WebAuthn contrôle si l'authentificateur doit vérifier l'utilisateur (biométrie, code PIN) avant de signer, ou s'il peut se contenter de la simple présence physique. Laissé sur sa valeur permissive plutôt que sur "required", un appareil déverrouillé ou volé peut suffire à valider une connexion sans second facteur réel.
• Une vérification d'origin ou de RP ID trop permissive. Le navigateur vérifie normalement que l'origine de la page correspond au Relying Party ID enregistré pour la passkey. Un RP ID configuré trop largement, par exemple sur un domaine racine partagé entre des sous-domaines aux niveaux de confiance différents, élargit la surface d'attaque à tout sous-domaine compromis.
• L'ajout d'une passkey sans réauthentification forte. Si votre site permet d'enrôler une nouvelle passkey depuis une session déjà ouverte, sans redemander une preuve d'identité forte, un attaquant qui vole un cookie de session ou exploite une faille XSS peut enregistrer sa propre passkey et conserver un accès persistant, même après que la victime a changé son mot de passe.
• La confiance aveugle dans la synchronisation cloud. La plupart des passkeys grand public sont synchronisées via un trousseau cloud. C'est un vrai confort d'usage, mais la sécurité de la passkey hérite alors de la sécurité du compte cloud qui la porte : un compte mal protégé redevient le maillon faible de toute la chaîne.
• Un flux multi-appareil manipulable par ingénierie sociale. Le flux qui permet de se connecter sur un ordinateur en scannant un QR code avec son téléphone ouvre une nouvelle surface d'ingénierie sociale : un site frauduleux peut présenter son propre QR code et pousser la victime à valider une connexion qui n'est pas la sienne, un scénario qui rappelle les attaques par fatigue de validation déjà vues sur les notifications push MFA.

Comment sécuriser concrètement votre implémentation

Rien de tout cela ne remet en cause l'intérêt des passkeys. Cela remet en cause la manière dont beaucoup de sites les branchent en surface, sans revoir le reste du parcours d'authentification. Quelques réglages concrets, côté code, à la création de la credential :

userVerification: "required", residentKey: "required"

Et côté produit, quelques principes qui ferment la plupart des trous décrits plus haut :

• Ne pas afficher de lien de repli par défaut : ne proposer le mot de passe ou l'OTP qu'après un vrai échec avéré, journalisé et limité en tentatives.
• Restreindre le RP ID au sous-domaine réellement concerné, jamais au domaine racine par défaut.
• Exiger une réauthentification forte avant tout ajout d'une nouvelle passkey sur un compte existant.
• Notifier l'utilisateur par courriel à chaque nouvelle passkey enregistrée, avec un lien de révocation immédiat.
• Traiter la récupération de compte en cas de perte d'appareil comme un flux aussi sensible que la connexion elle-même, pas comme une simple case "mot de passe oublié".

Notre lecture chez CZSyn

Chez CZSyn, nous voyons de plus en plus de clients nous demander d'ajouter un bouton "se connecter avec une passkey" sur leur site ou leur back-office, souvent pour cocher une case UX ou marketing. Le problème n'est jamais le bouton : il est dans tout ce qu'il y a autour, le flux de récupération, la politique de session, la notification des nouveaux appareils. Une passkey mal entourée ne fait que déplacer la faille, elle ne la supprime pas.

Notre recommandation pour une PME qui envisage les passkeys : traitez l'implémentation comme un projet de sécurité à part entière, avec un audit du parcours complet (inscription, connexion, récupération, gestion des appareils), pas comme une simple intégration de librairie. Le protocole WebAuthn a été conçu par des cryptographes sérieux et publié par le W3C. Le reste dépend de la rigueur de votre implémentation.

Sources primaires

• Dark Reading, « Flaws in Passkeys Implementation Mean Old Attacks Still Work ».
• W3C, spécification officielle Web Authentication (WebAuthn) Level 3.
• FIDO Alliance, documentation officielle « Passkeys ».
• MDN Web Docs, référence de la Web Authentication API.