La boucle WebAuthn : erreurs logiques courantes dans la poignée de main "sans mot de passe"

L’industrie de la cybersécurité traverse actuellement son changement le plus significatif depuis des décennies : la transition des “secrets partagés” (mots de passe) vers la “preuve de possession asymétrique” (passkeys). Basés sur la standard WebAuthn (FIDO2), les passkeys promettent un avenir immunisé contre le phishing, le credential stuffing et la fatigue liée à l’authentification par mémoire.

Cependant, à mesure que leur adoption s’intensifie en 2025, une tendance dangereuse apparaît. Les chercheurs en sécurité et les testeurs d’intrusion identifient un phénomène récurrent appelé la “boucle WebAuthn”. Cela se produit lorsque un protocole techniquement “impossible à phisher” est compromis par une logique d’implémentation défectueuse, notamment dans la poignée de main entre les requêtes frontend et la vérification backend.

Dans cette analyse approfondie, nous décomposons les incohérences techniques, les “pièges de la poignée de main” et les mécanismes de récupération critiques qui réintroduisent les failles de sécurité que les passkeys étaient censés éliminer.

1. L’anatomie d’une poignée de main WebAuthn moderne

Pour comprendre les défauts, il faut d’abord voir comment la poignée de main doit fonctionner. Contrairement à une connexion par mot de passe, qui consiste en une simple comparaison de chaînes, une cérémonie WebAuthn implique un échange complexe en trois étapes entre le Relying Party (votre serveur), le Client (le navigateur/le système d’exploitation) et l’Authentificateur (capteur biométrique ou clé de sécurité).

Le flux d’enregistrement :

Génération du défi : Le serveur envoie un défi cryptographiquement aléatoire et un ID de Relying Party (RP ID).

Création de la credential : L’appareil de l’utilisateur génère une nouvelle paire de clés publique-privée.

Attestation : L’appareil envoie la clé publique, un credentialID, et un “objet d’attestation” (preuve que la clé a été créée par un appareil légitime) au serveur.

Vérification : Le serveur valide la signature et stocke la clé publique.

Le flux d’authentification :

Demande d’assertion : Le serveur envoie un nouveau défi.

Signature : L’authentificateur signe le défi avec la clé privée.

Vérification de l’assertion : Le serveur utilise la clé publique stockée pour vérifier la signature.

Le “boucle” commence lorsque les développeurs traitent cette danse cryptographique complexe comme une soumission de formulaire API standard.

2. Défaut #1 : La faille de validation de l’origine & du RP ID

La fonctionnalité la plus puissante de WebAuthn est le Binding d’Origine. Un passkey créé pour bank.com ne peut pas être utilisé sur bänk.com (un site de phishing homographe). Le navigateur applique cela strictement. Cependant, le navigateur ne fait respecter qu’un seul côté du contrat.

La incohérence technique :

De nombreuses implémentations backend ne vérifient pas strictement le clientDataJSON renvoyé par l’authentificateur. Lors de la poignée de main, l’authentificateur fournit un objet encodé en base64 contenant l’origine où la cérémonie a eu lieu.

La faille logique : Si le code backend ne vérifie que la signature mais ignore la vérification manuelle du champ origin dans le clientDataJSON, cela crée une opportunité de “phishing relayé”. Un attaquant pourrait faire passer une cérémonie WebAuthn légitime via un domaine malveillant, et si le backend est laxiste, il acceptera une signature valide d’un origin “invalide”.

La correction 2025 : Toujours mettre en œuvre une liste blanche stricte des origines côté serveur. Dans un environnement multi-domaine (par ex., brand.co.uk et brand.com), utilisez les nouvelles requêtes d’origines liées (ROR) pour partager en toute sécurité les RP IDs entre domaines sans diminuer le niveau de sécurité.

3. Défaut #2 : Le “Défi statique” et la vulnérabilité de relecture

Une erreur courante dans l’implémentation WebAuthn est de traiter le “défi” comme un simple identifiant de session plutôt qu’un nonce cryptographique.

La incohérence technique :

Le défi doit être :

• Généré côté serveur.
• À haute entropie (au moins 16 octets).
• À durée limitée (temporairement).
• À usage unique.

La faille logique : Certains développeurs utilisent des défis statiques ou prévisibles (comme un ID utilisateur ou un timestamp) pour simplifier la nature “sans état” de leurs API. Si un défi est réutilisé ou persiste sur plusieurs sessions, un attaquant interceptant une assertion signée peut effectuer une attaque de relecture. Il n’a pas besoin de votre clé privée ; il lui suffit de renvoyer votre “preuve” valide précédente à un serveur qui ne vérifie pas si ce défi a déjà été “consommé”.

La correction 2025 : Utiliser un modèle “Challenge-Store-Verify”. Stocker le défi dans un cache côté serveur (comme Redis) avec un TTL de 60–120 secondes. Une fois la signature vérifiée, supprimer immédiatement le défi du cache.

4. Défaut #3 : Le “ paradoxe de la récupération ” (le maillon faible)

C’est la faille logique la plus critique dans l’écosystème “sans mot de passe”. Les passkeys sont essentiellement impossibles à phisher. Mais que se passe-t-il lorsqu’un utilisateur perd son téléphone ?

La incohérence technique :

Pour éviter les “verrouillages”, les services mettent en place une récupération de compte. Souvent, ils recourent aux “anciennes méthodes” :

• Codes OTP par SMS.
• Liens magiques par email.
• Questions de sécurité.

La faille logique : En proposant une récupération par OTP SMS, vous rendez votre implémentation de passkey sans valeur. Un attaquant ne cherchera pas à casser la cryptographie WebAuthn ; il cliquera simplement sur “J’ai perdu mon appareil” et lancera une attaque de changement de SIM ou une ingénierie sociale pour intercepter le code SMS.

La sécurité du compte “boucle” vers le maillon faible. En 2024, plus de 22 % des violations ont commencé par une utilisation abusive de credentials, ciblant souvent ces mécanismes de “fallback”.

La correction 2025 :

Encourager plusieurs passkeys : Inviter les utilisateurs à enregistrer un appareil de secours (par ex., un ordinateur portable et un téléphone) ou une clé matérielle (YubiKey).

Codes de récupération : Fournir des “codes de récupération” à usage unique que l’utilisateur doit stocker hors ligne.

Vérification d’identité : Pour les comptes de grande valeur, exiger un délai d’attente de 24 heures ou une vérification manuelle d’identité avant de permettre une réinitialisation de passkey.

5. Défaut #4 : Négligence de l’attestation & le problème du “Virtuel Authenticator”

Lors de l’enregistrement, le serveur peut demander une “Attestation”. C’est un certificat numérique du fabricant de l’appareil (Apple, Google, Yubico) prouvant que la clé publique a été générée dans une enclave sécurisée ou un module de sécurité matériel (HSM).

La incohérence technique :

De nombreuses bibliothèques utilisent par défaut l’attestation : “none” car la vérification des attestations est techniquement difficile et nécessite de maintenir une liste de certificats racines de confiance.

La faille logique : En ignorant l’attestation, votre serveur ne peut pas savoir si la “passkey” est réellement une clé sécurisée liée au matériel ou une “authentificateur virtuel” émulé par un script malveillant. Bien que les “Passkeys synchronisés” (comme ceux dans iCloud) aient rendu l’attestation plus complexe, les environnements d’entreprise doivent toujours appliquer des vérifications strictes.

La correction 2025 : Utiliser le service de métadonnées FIDO (MDS3). C’est une base de données centralisée des caractéristiques des authenticators. En vérifiant le MDS3, votre backend peut confirmer qu’une passkey provient d’un appareil doté d’un capteur biométrique et d’un stockage sécurisé, plutôt que d’un navigateur Chrome sans tête.

6. Défaut #5 : Désynchronisation frontend/backend et le “Succès Échec”

WebAuthn est un processus en plusieurs étapes. Dans de nombreuses SPA modernes (Single Page Applications) construites avec React ou Next.js, le frontend gère l’appel à navigator.credentials, et le backend gère la vérification.

La incohérence technique :

Un bug fréquent consiste à ce que le frontend “valide” la réponse de l’authentificateur puis indique simplement au backend, “L’utilisateur l’a signé, voici l’ID, connectez-le.”.

La faille logique : Le backend ne doit jamais faire confiance à un signal de “succès” du frontend. Dans plusieurs CVEs de 2024 (notamment affectant certains wrappers d’authentification Next.js), il a été découvert qu’un attaquant pouvait contourner la vérification WebAuthn en interceptant l’appel API du frontend et en injectant un statut “Succès”, que le backend acceptait sans vérifier réellement la signature cryptographique contre la clé publique stockée.

La correction 2025 : Le backend doit être la seule source de vérité. La seule tâche du frontend est de transporter les octets bruts du navigateur vers le serveur. Le serveur doit effectuer le traitement lourd : analyser l’authData, hasher le clientDataJSON, et effectuer la vérification de la signature RS256 ou ES256.

7. Comment “Fermer la boucle” : une checklist pour développeurs

Pour construire un système sans mot de passe réellement sécurisé, allez au-delà des tutoriels de base et traitez ces défauts logiques de front :

Application stricte de l’origine : Ne vous contentez pas de vérifier la signature. Analysez le clientDataJSON et assurez-vous que l’origine correspond exactement à votre domaine.

Stateless est dangereux : Assurez-vous que vos défis sont aléatoires, générés par le serveur, et consommés après utilisation.

L’UX “Passkey-First” : Si un utilisateur possède un passkey, ne montrez pas le champ “Mot de passe” par défaut. Cela évite qu’il soit phishé en entrant un mot de passe qu’il n’utilise plus.

Auditez vos mécanismes de secours : Si vous devez utiliser SMS comme sauvegarde, considérez cela comme un “état de sécurité dégradé”. Informez l’utilisateur par email et limitez les permissions du compte pendant 48 heures après une récupération par SMS.

Utilisez des bibliothèques vérifiées : Ne “fabriquez pas votre propre” logique WebAuthn. Utilisez des bibliothèques éprouvées comme SimpleWebAuthn, FIDO2-lib, ou des services gérés comme Clerk, Auth0, ou Passkeys.io qui gèrent MDS3 et la validation d’origine out of the box.

Conclusion : L’avenir est sans mot de passe, pas sans logique

Les passkeys représentent une avancée monumentale en matière de sécurité, mais ce n’est pas une solution “installer et oublier”. La boucle WebAuthn nous enseigne que les vulnérabilités majeures résident souvent dans les transitions — les échanges entre le navigateur et le serveur, et le passage du mode “sécurisé” au mode “récupération”.

En se concentrant sur les incohérences techniques entre la commodité du frontend et la rigueur du backend, les développeurs peuvent garantir que la promesse “sans mot de passe” réalise réellement son objectif : un web où votre identité vous appartient, et à personne d’autre.