Pourquoi les clés d'accès sont-elles sécurisées ? — Le mécanisme de « l'authentification qui n'envoie jamais de secret » expliqué en schémas

« Encore une fuite de mots de passe chez un grand service » : ce genre de nouvelle ne surprend plus personne. Même en menant des formations anti-hameçonnage chaque année, le nombre de personnes qui se font piéger ne tombe jamais à zéro. « Ne réutilisez pas vos mots de passe, allongez-les, le changement périodique… ce n’est finalement plus nécessaire » — les recommandations elles-mêmes n’ont cessé de changer.

La clé d’accès (passkey), qui s’est répandue très rapidement ces dernières années, est la réponse à cette situation : une méthode d’authentification poussée conjointement par Apple, Google et Microsoft.¹ On la présente souvent comme « pratique, car on peut se connecter avec son empreinte ou son visage », mais ce n’est pas là l’essentiel. La véritable valeur de la clé d’accès est d’avoir déplacé le fondement de la sécurité, de « la vigilance humaine » vers « la structure du protocole ».

• Si les mots de passe fuitent, c’est par manque de vigilance de l’utilisateur : formons-le → l’être humain se trompe toujours
• Entraînons-le à repérer les faux sites → on peut créer un faux site impossible à repérer
• Avec une clé d’accès → il n’y a tout simplement aucun secret à envoyer, et sur un faux site, la signature ne peut pas aboutir

Cet article explique en images pourquoi la clé d’accès est sécurisée, en partant de ce qui est cassé dans le mot de passe. Nous répondrons ensuite frontalement aux questions naturelles que cela soulève — « une clé d’accès synchronisée est-elle vraiment sûre ? », « n’y a-t-il aucune faiblesse ? » — avant de récapituler, pour finir, les points pratiques à connaître pour la mettre en œuvre dans une application web ou un environnement Windows.

1. La conclusion, d’abord

Les raisons pour lesquelles la clé d’accès est sécurisée se résument à ces trois points.

1. Le serveur ne détient aucun secret. Ce qu’il conserve est uniquement la clé publique, une information qui ne peut être exploitée même en cas de fuite. Même si toute la base de données est dérobée, l’attaquant ne repart avec aucun « matériau permettant l’usurpation ».²
2. Le secret ne circule jamais sur le réseau. Ce qui est envoyé lors de la connexion n’est que la signature d’un nombre aléatoire à usage unique (le challenge). Comme la clé privée ne sort jamais de l’authentificateur de l’appareil, aucune interception ni aucun relais, où que ce soit sur le trajet, ne permet de récupérer le secret.²
3. Sur un faux site, la signature ne peut pas aboutir. La clé d’accès est liée au domaine du site, et le navigateur impose la vérification de ce domaine. Même si l’utilisateur se laisse tromper par un faux site, la clé d’accès du vrai site n’apparaît jamais parmi les options, et même si la signature était relayée, elle serait rejetée à la vérification.³

Ces trois points ne sont pas des astuces indépendantes : ils découlent tous d’un seul et même changement de conception, le passage d’une authentification qui « partage et envoie un secret » à une authentification qui « prouve par signature que l’on détient le secret ». Voyons cela dans l’ordre.

Les liens entre les termes — clé d’accès, WebAuthn, FIDO2, CTAP

Ce domaine compte de nombreux termes, dont la portée varie selon les articles ; commençons donc par clarifier les liens entre eux. La clé d’accès n’est pas un nouveau protocole : c’est le « nom » donné à une combinaison de standards déjà existants.²¹

Tableau 1 : la clé d’accès est un nom donné au-dessus du socle FIDO2, et non le nom d’un standard en soi

Autrement dit, « prendre en charge la clé d’accès » signifie, en langage d’implémentation, « implémenter WebAuthn ». CTAP est la couche dont le navigateur et le système d’exploitation se chargent lorsqu’un authentificateur externe est utilisé, si bien que celui qui développe l’application web n’a jamais à la manipuler directement.

2. Ce qui est cassé dans l’authentification par mot de passe

Le moyen le plus rapide de comprendre la sécurité de la clé d’accès est de repérer les faiblesses du mot de passe par leur « emplacement ». Dans l’authentification par mot de passe, le secret lui-même parcourt tout le trajet à chaque authentification.

sequenceDiagram
    participant U as Utilisateur
    participant B as Navigateur
    participant S as Serveur
    Note over U: Détient le secret (mot de passe) dans sa tête<br/>【Faiblesse ①】devinable, réutilisé
    U->>B: Saisit le mot de passe
    Note over B: 【Faiblesse ②】Peut être saisi de la même façon<br/>sur un faux site (indiscernable visuellement)
    B->>S: Envoie le mot de passe lui-même
    Note over B,S: 【Faiblesse ③】Le secret circule sur le trajet<br/>Protégé par TLS, mais revient en clair au point d'arrivée
    S->>S: Vérifie par comparaison avec le hachage stocké
    Note over S: 【Faiblesse ④】Les secrets (hachés) de tous les utilisateurs s'accumulent<br/>En cas de fuite, cible d'une attaque par force brute hors ligne

Figure 1 : dans l’authentification par mot de passe, le secret lui-même est présent sur tout le trajet

Du point de vue de l’attaquant, cette structure offre de nombreuses cibles faciles à atteindre.

• Faiblesse ① (l’utilisateur) : sa robustesse se limite à ce qui reste mémorisable, et il est réutilisé sur plusieurs sites. Une fuite à un seul endroit se propage à tous les comptes (attaque par « credential stuffing »).
• Faiblesse ② (l’instant de la saisie) : il suffit de préparer un faux site indiscernable du vrai pour que l’utilisateur livre lui-même son secret (l’hameçonnage).
• Faiblesse ③ (le trajet) : TLS rend l’interception du trajet lui-même difficile, mais cela perd tout son sens si un « point de relais à l’apparence légitime » s’intercale (l’AiTM, décrit plus loin).
• Faiblesse ④ (le serveur) : même stocké sous forme de hachage, si la base de données fuite, elle peut être soumise à une attaque par force brute hors ligne. Les mots de passe les plus faibles cèdent les premiers.

« Alors, il suffirait d’ajouter un code à usage unique (SMS ou TOTP) » : c’est l’authentification multifacteur traditionnelle, mais elle non plus ne change rien à la structure consistant à envoyer un secret partagé. Le TOTP repose sur une graine (un secret) partagée entre le serveur et l’application d’authentification, et le code à six chiffres généré peut, en fin de compte, toujours être saisi par l’utilisateur sur un faux site. De fait, l’hameçonnage de type AiTM (Adversary-in-the-Middle), où le faux site relaie en temps réel vers le vrai serveur, franchit cette barrière en faisant simplement transiter le couple mot de passe + code à usage unique. C’est pourquoi la CISA (l’agence américaine de cybersécurité) ne cite, comme « MFA résistante à l’hameçonnage », que deux méthodes — l’authentification FIDO/WebAuthn et l’authentification basée sur une PKI comme la carte à puce (PIV/CAC) — et positionne FIDO comme la référence absolue.⁴

Autrement dit, le problème ne réside pas dans la « robustesse » du mot de passe, mais dans la structure même qui consiste à partager un secret et à l’envoyer à chaque authentification.

3. Ce qu’est réellement une clé d’accès — prouver que l’on détient un secret sans jamais l’envoyer

La clé d’accès est un identifiant basé sur la cryptographie à clé publique, construit sur deux standards — WebAuthn du W3C et CTAP de la FIDO Alliance (ensemble, FIDO2).²¹ Cela peut sembler complexe, mais la structure est simple.

flowchart LR
    subgraph DEV["Appareil de l'utilisateur"]
        AUTH["Authentificateur (coffre-fort)<br/>Windows Hello / Face ID /<br/>Verrouillage d'écran Android / Clé de sécurité"]
        SK["Clé privée<br/>ne sort jamais d'ici"]
        BIO["Empreinte / visage / PIN<br/>= sert uniquement à ouvrir la porte du coffre<br/>ne sort pas non plus"]
        AUTH --- SK
        BIO -->|"Vérification locale"| AUTH
    end
    subgraph SRV["Serveur"]
        PK["Clé publique<br/>inexploitable même en cas de fuite<br/>information « réservée à la vérification »"]
    end
    SK -.->|"Paire mathématique<br/>(côté qui crée la signature)"| PK

Figure 2 : une clé d’accès est en réalité une paire de clés propre à chaque site. La partie privée ne sort jamais de l’appareil, et le serveur ne détient que la clé publique servant à la vérification

• La clé privée est celle qui peut créer une signature ; elle est conservée dans l’authentificateur de l’appareil (Windows Hello, Face ID/Touch ID sur iPhone, verrouillage d’écran Android, ou une clé de sécurité comme une YubiKey) et n’en sort jamais.
• La clé publique ne peut que vérifier une signature ; c’est elle qui est confiée au serveur. Comme il est calculatoirement impossible de retrouver la clé privée à partir de la clé publique, c’est une information qui peut fuiter sans conséquence.
• Les données biométriques comme l’empreinte ou le visage servent uniquement à ouvrir localement la porte du coffre-fort, et elles non plus ne sortent jamais de l’appareil. Aucune donnée biométrique n’est jamais envoyée au serveur.¹

Enregistrement : ne transmettre « que » la clé publique

Voici le déroulement de l’enregistrement d’une clé d’accès sur un site.

sequenceDiagram
    participant S as Serveur (example.com)
    participant B as Navigateur
    participant A as Authentificateur
    S->>B: Demande d'enregistrement (challenge aléatoire + informations du site)
    B->>A: Crée une clé pour ce site (example.com)
    A->>A: Vérifie l'identité par empreinte, visage ou PIN (localement)
    A->>A: Génère une nouvelle paire de clés<br/>la clé privée est conservée en interne
    A->>B: Clé publique + credential ID (l'étiquette de la clé)
    B->>S: Envoie la clé publique + le credential ID
    S->>S: Enregistre comme clé publique de ce compte
    Note over S: Le serveur n'a reçu que<br/>« une information inexploitable même en cas de fuite »

Figure 3 : lors de l’enregistrement, seule la clé publique circule sur le réseau et se retrouve stockée sur le serveur

Ce qui compte, c’est qu’à ce moment-là, la paire de clés est créée en étant liée au domaine du site (le RP ID). Une clé d’accès créée pour example.com ne peut être utilisée que sur le site example.com (le RP ID étant défini par domaine, elle reste utilisable depuis une page d’un sous-domaine du même domaine, comme login.example.com, mais pas depuis un domaine sans rapport). Ce lien constitue le fondement de la résistance à l’hameçonnage décrite plus loin.³

De plus, une nouvelle paire de clés est créée pour chaque site. Comme la clé d’accès du site A et celle du site B sont mathématiquement sans rapport, la notion même de « réutilisation » n’existe pas, et elles ne peuvent pas non plus servir à recouper l’identité d’un utilisateur entre plusieurs sites.

Authentification : renvoyer une signature valable uniquement pour l’instant présent

Voici le déroulement lors de la connexion. Comparez-le à l’authentification par mot de passe (figure 1).

sequenceDiagram
    participant S as Serveur (example.com)
    participant B as Navigateur
    participant A as Authentificateur
    S->>B: Demande de connexion (challenge aléatoire à usage unique)
    B->>A: Demande une signature pour example.com
    A->>A: Vérifie l'identité par empreinte, visage ou PIN (localement)
    A->>A: Crée la signature avec la clé privée<br/>en y intégrant le challenge + l'origine + le hachage du RP ID
    A->>B: Signature (jamais la clé privée elle-même)
    B->>S: Envoie la signature
    S->>S: Vérifie la signature avec la clé publique stockée<br/>et contrôle aussi le challenge, l'origine et le RP ID
    Note over B,S: Seule une signature à usage unique circule sur le trajet<br/>même volée, elle est inutilisable pour le prochain challenge

Figure 4 : lors de l’authentification non plus, le secret ne se déplace jamais. Ce qui circule n’est qu’une « pièce justificative valable sur l’instant »

Le serveur propose à chaque fois un nouveau nombre aléatoire (le challenge), et l’authentificateur signe « ce challenge + l’origine actuellement vue par le navigateur + le hachage du RP ID ». Le serveur vérifie la signature avec la clé publique qu’il conserve, et s’assure que le challenge est bien celui qu’il a proposé, et que l’origine et le RP ID correspondent bien à son propre site.⁵

Conséquence de cette conception : deux des trois raisons énoncées au début sont déjà acquises.

• Le serveur n’a aucun secret : ce qu’il conserve n’est que la clé publique. Même en cas de fuite, l’attaquant ne peut pas fabriquer de signature, et ne peut donc pas la « ramener chez lui pour la casser », contrairement au hachage d’un mot de passe.
• Le secret ne circule jamais : même en volant la signature sur le trajet, le challenge étant à usage unique, elle ne peut pas être réutilisée (attaque par rejeu).

Reste le dernier point, « sur un faux site, la signature ne peut pas aboutir » : c’est le plus grand atout de la clé d’accès. Nous y consacrons une section à part.

4. Pourquoi l’hameçonnage est « structurellement » impossible

L’hameçonnage réussit contre un mot de passe parce qu’il est possible de saisir le vrai secret sur un faux site. Un être humain ne distingue pas example.com de examp1e.com (surtout lorsqu’il est fatigué), mais le champ de saisie du mot de passe fonctionne de la même façon sur les deux sites.

Avec la clé d’accès, ce n’est plus l’humain mais le navigateur qui effectue cette vérification de façon mécanique. Selon les spécifications de WebAuthn, le navigateur ne peut appeler l’authentificateur que si « le domaine de l’origine actuellement affichée » correspond au « RP ID de la clé d’accès ».³ Voici, en image, ce qui se passe au moment où l’on accède à un faux site.

sequenceDiagram
    participant U as Utilisateur
    participant B as Navigateur
    participant P as Faux site (examp1e.com)<br/>proxy AiTM relayant vers le vrai site
    participant S as Vrai serveur (example.com)
    U->>P: Accède à un écran de connexion visuellement identique
    P->>S: (En coulisses) démarre le vrai processus de connexion
    S->>P: Challenge
    P->>B: Fait suivre le challenge et demande une signature
    B->>B: L'origine actuelle est examp1e.com<br/>impossible de proposer la clé d'accès prévue pour example.com
    B--xP: Aucune signature n'est créée (l'utilisateur ne peut pas se faire tromper)
    Note over B,S: Même si une signature était créée par un quelconque moyen,<br/>elle intégrerait examp1e.com<br/>et serait donc forcément rejetée à la vérification du vrai serveur

Figure 5 : l’hameçonnage de type AiTM franchit la barrière du mot de passe + code à usage unique, mais avec une clé d’accès, il échoue dès l’étape de la signature

Notez que la défense est ici doublée.

1. Elle n’apparaît pas parmi les options : le navigateur n’énumère que les clés d’accès dont le RP ID correspond à l’origine. Sur un faux domaine, la clé d’accès du vrai site n’apparaît jamais parmi les choix, si bien que l’utilisateur ne peut même pas « l’utiliser par mégarde ».
2. La signature ne passe pas : l’objet signé inclut l’origine et le hachage du RP ID tels que vérifiés par le navigateur. Le vrai serveur les contrôle lors de la vérification, donc une signature créée depuis une autre origine est toujours rejetée.⁵

Les mesures anti-hameçonnage pour le mot de passe reposaient sur l’effort humain — « l’utilisateur doit bien regarder l’URL ». Avec la clé d’accès, l’utilisateur n’a tout simplement pas besoin de repérer le faux site. C’est là le sens exact du terme « résistant à l’hameçonnage » (phishing-resistant), et la raison pour laquelle la CISA et le NIST (l’institut américain de normalisation) réservent un traitement particulier à la méthode FIDO/WebAuthn.⁴⁶

Récapitulons ce qui précède, technique d’attaque par technique d’attaque.

Tableau 2 : comparaison de la résistance par technique d’attaque. Chaque « ○ » de la clé d’accès provient de la structure, et non de l’exploitation ou de la vigilance

5. La « clé d’accès synchronisée » est-elle sûre ?

En lisant les explications précédentes, une question vient naturellement à l’esprit : « vous avez dit que la clé privée ne sortait jamais de l’appareil, alors pourquoi une clé d’accès créée sur un iPhone fonctionne-t-elle aussi sur un iPad ? » — bonne question, et la réponse est qu’il existe deux types de clés d’accès.

Voici d’abord un tableau récapitulatif de la conclusion. Considérez que cette section et la suivante expliquent pourquoi chaque ligne de ce tableau est ce qu’elle est.

Tableau 3 : aide-mémoire comparant les types synchronisé et lié à l’appareil. Le choix dépend de ce que l’on privilégie entre « la résistance à la perte » et « la capacité à contrôler l’emplacement de la clé »

flowchart TB
    subgraph SYNC["Clé d'accès synchronisée (par défaut pour le grand public)"]
        S1["Trousseau iCloud /<br/>Gestionnaire de mots de passe Google /<br/>gestionnaires comme 1Password"]
        S2["Synchronisée en chiffré de bout en bout<br/>entre les appareils du même compte<br/>le fournisseur ne peut pas non plus en lire le contenu"]
        S3["Avantage : résiste bien au changement d'appareil et à la perte<br/>Attention : la protection du compte cloud lui-même est indispensable"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["Clé d'accès liée à l'appareil"]
        B1["Clé de sécurité (YubiKey, etc.) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["La clé privée ne sort jamais<br/>physiquement de ce matériel (protégée par le TPM, etc.)"]
        B3["Avantage : l'emplacement de la clé est clair, en un seul endroit<br/>Attention : enregistrer plusieurs clés est indispensable en prévision d'une perte"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

Figure 6 : type synchronisé et type lié à l’appareil. Les deux partagent le principe de « ne jamais envoyer la clé privée au serveur », mais l’endroit où porter l’effort de protection diffère

La clé d’accès synchronisée est celle dont la clé privée est synchronisée entre les appareils d’un même compte par le trousseau iCloud ou le gestionnaire de mots de passe Google. Ce qui compte ici, c’est que cette synchronisation est chiffrée de bout en bout. Apple comme Google affirment explicitement que la clé d’accès est chiffrée sur l’appareil avant d’être synchronisée, et que le fournisseur lui-même ne peut pas en lire le contenu.⁷⁸ Autrement dit, le principe « la clé privée ne sort jamais de l’appareil » est assoupli, plus précisément, en « la clé privée ne sort jamais de l’appareil en clair », en échange d’une résistance au changement d’appareil et à la perte.

Il faut clairement expliciter comment cet assouplissement modifie le modèle de menace : l’endroit à protéger se concentre, passant de « chaque serveur de chaque site » à « un seul compte cloud ». La résistance aux fuites de base de données et à l’hameçonnage de chaque site reste intacte, mais désormais, le piratage du compte Apple ID ou Google lui-même devient le point de défaillance unique. C’est précisément pourquoi il est indispensable d’appliquer la protection la plus forte possible (verrouillage d’écran robuste, moyens de récupération bien organisés, et si possible une clé de sécurité physique) au compte de plateforme auquel on confie ses clés d’accès. Le NIST a lui aussi publié, en avril 2024, un supplément à NIST SP 800-63B (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B), positionnant officiellement le fait qu’une clé d’accès synchronisée (syncable authenticator) puisse satisfaire le niveau gouvernemental AAL2 (Authenticator Assurance Level 2, niveau d’assurance de l’authentificateur 2) si les exigences sont remplies. Cependant, la clé privée restant susceptible d’être exportée, le type synchronisé ne doit pas être utilisé pour l’AAL3, qui exige un environnement isolé par le matériel.⁶

La clé d’accès liée à l’appareil est le type dont la clé privée ne sort jamais du matériel. Une clé de sécurité comme la YubiKey en est l’exemple typique, et côté entreprise, la clé d’accès de Microsoft Entra ID (celle créée dans Microsoft Authenticator) relève également de ce type.⁹ Windows Hello sous Windows protège lui aussi la clé privée sous le TPM lorsque celui-ci est disponible. Ce mécanisme même de « coffre-fort matériel qui ne laisse jamais sortir la clé » repose sur le même socle que celui détaillé dans l’article sur le TPM.

Vous vous êtes peut-être déjà demandé pourquoi on vous fait scanner un code QR lorsque vous « vous connectez à un navigateur sur PC avec la clé d’accès de votre smartphone ». Ce n’est pas une simple transition d’écran : c’est la méthode hybride (l’authentification cross-device de FIDO) qui confirme la proximité physique entre le smartphone et le PC via Bluetooth. Cette vérification de proximité neutralise l’attaque par laquelle un attaquant distant ferait approuver, via un code QR, une connexion à son propre PC par une autre personne.¹

6. Ce n’est pas une solution miracle — la faiblesse ne « disparaît » pas, elle « se déplace »

Nous avons expliqué jusqu’ici la force de la clé d’accès, mais, pour être honnête, elle ne fait pas disparaître les attaques : c’est une technologie qui repousse l’attaquant vers des endroits plus faibles. Voici, en image, où se reporte l’attaquant lorsque la porte d’entrée de l’authentification se durcit.

flowchart LR
    A["Attaquant"]
    G["L'authentification elle-même<br/>signature du challenge<br/>【Solide】"]
    R["Flux de récupération de compte<br/>déclarer avoir « perdu sa clé d'accès »,<br/>se faire réinitialiser par SMS ou e-mail,<br/>et enregistrer la clé d'accès de l'attaquant"]
    F["Solutions de repli coexistantes<br/>si la connexion par mot de passe ou par SMS<br/>subsiste, le maillon le plus faible est là"]
    C["Compte cloud<br/>pour le type synchronisé, l'identifiant Apple ou<br/>le compte Google est le point de défaillance unique"]
    SS["Session<br/>voler le cookie après la connexion<br/>rend la méthode d'authentification sans importance"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

Figure 7 : lorsque la porte d’entrée (l’authentification) se durcit, l’attaque se déplace vers le flux de récupération, les solutions de repli coexistantes, le compte cloud et la session

Il existe quatre risques résiduels à connaître en pratique.

1. Une solution de repli coexistante devient le maillon le plus faible. Se contenter de rendre la clé d’accès « également » utilisable, tout en conservant la connexion par mot de passe ou par SMS, ne fait que donner à l’attaquant l’option d’utiliser cette dernière. La résistance à l’hameçonnage, considérée à l’échelle du compte tout entier, est limitée par le niveau du moyen de connexion le plus faible. L’essentiel de la mise en œuvre n’est donc pas d’ajouter la clé d’accès, mais de réduire et de retirer méthodiquement les solutions de repli.
2. Le flux de récupération devient une nouvelle surface d’attaque. Une technique consiste à prétendre faussement avoir « perdu son appareil » pour amener le support client ou une réinitialisation par e-mail à enregistrer la propre clé d’accès de l’attaquant. De fait, l’ingénierie sociale qui contourne une authentification robuste en trompant le service d’assistance est devenue une méthode courante lors de compromissions à grande échelle. Plus l’authentification se durcit, plus la conception de la vérification d’identité du flux de récupération devient un enjeu.
3. Pour le type synchronisé, le compte cloud constitue le point de défaillance unique. Comme expliqué à la section précédente. La protection du compte auquel les clés d’accès sont confiées, ainsi que, dans un cadre organisationnel, la décision de la politique sur « quelles plateformes de synchronisation autoriser », sont nécessaires.
4. Le vol de session n’est pas empêché. La clé d’accès ne protège que l’instant de la connexion ; si le cookie de session après la connexion est volé par un logiciel malveillant ou une faille XSS, la méthode d’authentification n’y change rien. La gestion de la durée de validité des jetons, de leur liaison et de l’intégrité de l’appareil reste un travail à part, sur une autre couche.

Cela ne signifie pas qu’il faille renoncer à la clé d’accès. C’est simplement une évidence : moderniser la serrure de la porte d’entrée ne dispense pas de verrouiller les fenêtres, qui reste un travail à part. Au contraire, l’emplacement des faiblesses devenant plus clair, il devient possible de concentrer les ressources de défense sur le flux de récupération et la gestion des sessions.

7. La mise en œuvre en pratique — l’API WebAuthn et l’environnement Windows

Pour finir, voici les points clés du point de vue de celui qui met en œuvre la clé d’accès.

Ajouter la connexion par clé d’accès à son propre service web

Côté navigateur, il n’y a que deux fonctions de l’API WebAuthn : navigator.credentials.create() pour l’enregistrement, et navigator.credentials.get() pour l’authentification.

// Enregistrement (côté navigateur)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // Nombre aléatoire à usage unique généré par le serveur
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // En faire un identifiant découvrable (= une clé d'accès)
      userVerification: "required",   // Rendre obligatoire la vérification d'identité par biométrie/PIN
    },
  },
});
// La clé publique se récupère depuis credential.response, et le credential ID
// depuis credential.id / credential.rawId au niveau supérieur. La réponse
// d'enregistrement doit elle aussi être vérifiée côté serveur (challenge,
// origine, RP ID) avant d'être enregistrée, comme lors de l'authentification

Voici la signification des principaux paramètres.

Tableau 4 : principaux paramètres de navigator.credentials.create()

Remarque sur l’environnement de test : l’API WebAuthn n’est exposée que dans un contexte sécurisé, si bien que l’appel à navigator.credentials échoue sur une page servie en simple http://. L’exception est http://localhost (et 127.0.0.1), traités comme des origines de confiance : vous pouvez donc les tester tels quels sur une machine de développement, sans passer en HTTPS. Cependant, le RP ID devant être le domaine effectif de l’origine (ou l’un de ses domaines parents), une clé d’accès créée sur localhost ne peut pas être utilisée sur le domaine de production. Même sans authentificateur physique sous la main, activer l’authentificateur virtuel dans l’onglet « WebAuthn » des outils de développement Chrome permet de dérouler tout le processus, de l’enregistrement à l’authentification.

// Authentification (côté navigateur)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // Propose la clé d'accès comme suggestion d'auto-remplissage du champ de connexion.
  // Vérifier au préalable la prise en charge avec
  // PublicKeyCredential.isConditionalMediationAvailable(), et sur les navigateurs
  // non compatibles, se replier sur un appel classique sans mediation
  mediation: "conditional",
  // (nécessite que le <input> ciblé porte autocomplete="username webauthn")
});
// Vérifier côté serveur la signature de assertion.response

L’essentiel se joue dans la vérification côté serveur. Il faut au minimum toujours effectuer ce qui suit.⁵

• Vérification du challenge : s’agit-il d’un challenge émis par nous et non encore utilisé ? Est-il consommé à usage unique (protection contre le rejeu) ? Il faut de plus le stocker en le liant à la session du navigateur (la tentative de connexion) au moment de son émission, et n’en autoriser la consommation que pour une réponse issue de cette même session. Si ce point est relâché, un attaquant peut faire passer, via le navigateur de la victime, la signature d’un challenge qui lui est destiné, et ainsi faire connecter la victime au propre compte de l’attaquant (une CSRF de connexion).
• Vérification de l’origine : le champ origin de clientDataJSON correspond-il bien à l’origine légitime de notre site (le pivot de la protection anti-hameçonnage) ?
• Vérification du hachage du RP ID : le rpIdHash de authenticatorData correspond-il au SHA-256 du RP ID de notre site ?
• Vérification du type de cérémonie et des drapeaux : le champ type de clientDataJSON vaut-il bien webauthn.get pour une authentification et webauthn.create pour un enregistrement ? Le drapeau UP (User Present, présence de l’utilisateur) de authenticatorData est-il activé ? Si la vérification de l’utilisateur (UV) a été demandée, le drapeau UV est-il lui aussi activé ?
• Vérification de la signature : la signature se vérifie-t-elle correctement avec la clé publique enregistrée lors de l’inscription ?
• Association au compte : le credential ID présenté (et le userHandle) est-il recherché dans notre propre base de données, et la session est-elle bien délivrée au titulaire de cet identifiant ? Faire confiance sans condition à un nom d’utilisateur saisi séparément crée une faille permettant de connecter, avec une signature pourtant valide, en tant qu’une autre personne.
• Stockage et comparaison du compteur de signature : stocker le signCount de authenticatorData pour chaque identifiant, et vérifier que la valeur suivante est bien supérieure à la précédente. Une valeur inférieure ou égale (y compris égale) à la précédente doit être traitée comme un signe possible de clonage de l’authentificateur. Cependant, comme de nombreuses implémentations de clés d’accès synchronisées renvoient toujours 0, il convient de tolérer en exception le seul cas où les deux valeurs valent 0.

Écrire cette vérification à la main soi-même est une source classique d’accidents : utilisez une bibliothèque ayant fait ses preuves (fido2-net-lib pour .NET, SimpleWebAuthn pour Node.js, par exemple). Il est judicieux de laisser à la bibliothèque les détails de la spécification — l’analyse du CBOR, la négociation des algorithmes, la gestion des challenges — et de concentrer ses propres efforts sur le stockage et la révocation des challenges, l’interface de gestion des clés d’accès multiples, et la conception du flux de récupération.

Le cas de l’environnement Windows et des systèmes internes

Pour le lectorat de ce site — les personnes en charge de systèmes métier Windows — il suffit de retenir les trois points suivants.

• Le client Windows est déjà pris en charge. Windows 11 prend en charge la création, l’utilisation et la gestion des clés d’accès (Paramètres > Comptes > Clés d’accès) avec Windows Hello comme authentificateur, et la clé privée est protégée matériellement si un TPM est présent.¹⁰ WebAuthn via le navigateur (Edge/Chrome) fonctionne aussi sous Windows 10.
• Dans un environnement Entra ID, activer « la clé d’accès = la méthode d’authentification FIDO2 ». Microsoft Entra ID prend en charge les clés de sécurité et les clés d’accès (liées à l’appareil) de l’application Microsoft Authenticator ; en exigeant la « MFA résistante à l’hameçonnage » dans la force d’authentification de l’accès conditionnel, vous pouvez limiter l’accès aux ressources ciblées à la clé d’accès ou équivalent.⁹ La migration depuis le monde du NTLM et des politiques d’expiration de mot de passe ne se fait pas d’un seul coup ; la pratique standard consiste à rendre la MFA résistante à l’hameçonnage obligatoire d’abord pour les comptes administrateurs, en parallèle de l’inventaire de l’infrastructure d’authentification traité dans l’article sur NTLM et Kerberos.
• Le bénéfice est le même pour une application web interne. À condition, toutefois, que HTTPS soit en place. L’API WebAuthn ne fonctionnant que dans un contexte sécurisé, même pour une application intranet (hormis le localhost en développement), le passage en HTTPS et la mise en place d’un nom de domaine interne utilisable comme RP ID sont des préalables. Une fois cela réglé, le RP ID fonctionne tout aussi bien pour un domaine interne. Pour ce qui est de rompre avec le mot de passe sur post-it, il n’est pas rare que les effets se fassent sentir plus vite en interne que sur un service tourné vers l’extérieur.

8. Conclusion

• La faiblesse du mot de passe ne réside pas dans sa robustesse, mais dans la structure même qui consiste à partager un secret et à l’envoyer à chaque authentification. Comme le secret existe partout à la fois — chez l’utilisateur, dans le champ de saisie, sur le trajet et sur le serveur — les cibles d’attaque sont nombreuses. Même en ajoutant un code à usage unique, l’hameçonnage de type AiTM finit par le relayer et par l’emporter.
• La clé d’accès est une paire de clés de cryptographie à clé publique propre à chaque site : elle ne transmet au serveur qu’une clé publique inexploitable même en cas de fuite, et n’envoie, lors de la connexion, que la signature d’un challenge à usage unique. Le serveur ne détient aucun secret, et aucun secret ne circule non plus sur le trajet.
• Comme la signature intègre l’origine et le RP ID vérifiés par le navigateur, sur un faux site, la clé d’accès du vrai site n’apparaît jamais parmi les options, et même relayée, elle échoue à la vérification. Le fait que l’utilisateur n’ait pas besoin de repérer le faux site est le véritable sens de la « résistance à l’hameçonnage », et le fondement de la défense est passé de la vigilance humaine à la structure du protocole.
• La clé d’accès synchronisée est synchronisée par chiffrement de bout en bout et résiste bien au changement d’appareil et à la perte. En contrepartie, l’endroit à protéger se concentre sur le compte cloud, si bien que la défense du compte Apple ID/Google lui-même devient un préalable indispensable. Les entreprises peuvent aussi choisir le type lié à l’appareil (clé de sécurité, clé d’accès Authenticator d’Entra ID).
• La clé d’accès ne fait pas disparaître les attaques, elle les repousse vers des endroits plus faibles. Le mot de passe coexistant, le flux de récupération de compte et le vol de session demeurent des surfaces d’attaque ; l’essentiel de la mise en œuvre réside dans la réduction planifiée des solutions de repli et le renforcement du flux de récupération.
• L’implémentation repose sur les deux fonctions create / get de l’API WebAuthn, plus la vérification côté serveur. Ne pas réinventer la vérification soi-même : la confier à une bibliothèque éprouvée, et consacrer ses efforts à la gestion des challenges, à l’interface de gestion des clés d’accès multiples et à la conception de la récupération.

Articles connexes

• Qu’est-ce que le TPM de Windows ? — Le « coffre-fort qui ne laisse jamais sortir la clé » et le démarrage mesuré expliqués en schémas
• NTLM et Kerberos expliqués en schémas — pourquoi l’authentification « retombe »-t-elle sur NTLM ?
• Intégrer l’authentification Entra ID dans une application WinForms/WPF — configuration pratique avec MSAL.NET et le courtier WAM
• Gérer les identifiants en toute sécurité avec PowerShell — bannir les mots de passe en clair des scripts
• Liste de contrôle de sécurité minimale pour le développement d’applications Windows
• Sécurité des PME : par où commencer ? — parcourir la version 4.0 des « Directives de sécurité de l’information pour les PME » de l’IPA

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) propose du développement sous contrat couvrant l’accompagnement de l’implémentation WebAuthn pour la connexion par clé d’accès dans les systèmes web internes, la conception du déploiement d’une MFA résistante à l’hameçonnage en environnement Entra ID, et l’intégration de l’authentification dans les applications métier Windows telles que WinForms/WPF.

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quelle est la différence fondamentale entre une clé d'accès et un mot de passe ?

Le mot de passe repose sur un mécanisme où « l'utilisateur et le serveur partagent le même secret, et ce secret est envoyé à chaque connexion ». Comme ce secret existe partout à la fois — dans la tête de l'utilisateur, dans le champ de saisie, sur le chemin de communication et dans la base de données du serveur — chacun de ces endroits devient une cible d'attaque. La clé d'accès utilise, elle, une paire de clés de cryptographie à clé publique, et la clé privée n'est jamais envoyée au serveur. Dans le cas d'une clé d'accès liée à l'appareil, la clé privée ne sort jamais de l'authentificateur ; même pour une clé d'accès synchronisée, elle ne sort de l'appareil que sous une forme chiffrée de bout en bout. Ce que le serveur conserve est uniquement la clé publique, une « information qui ne peut être exploitée même si elle fuit », et ce qui est envoyé lors de la connexion n'est que la signature d'un challenge à usage unique. Autrement dit, le « secret partagé » qui constituait la faiblesse du mot de passe n'existe tout simplement pas. De plus, comme une paire de clés distincte est créée pour chaque site, la notion même de réutilisation ne peut pas exister.

Les données biométriques (empreinte digitale, visage) sont-elles envoyées au serveur ?

Non. Les données d'empreinte digitale ou de visage servent uniquement à une vérification locale, à l'intérieur de l'appareil, dont le seul rôle est « d'ouvrir la porte du coffre-fort contenant la clé privée » ; par conception, FIDO ne prévoit jamais l'envoi de données biométriques hors de l'appareil. Ce que reçoit le serveur, c'est uniquement une signature portant le drapeau indiquant que « la vérification de l'identité de l'utilisateur (vérification de l'utilisateur) a eu lieu » — elle ne contient ni l'empreinte elle-même, ni même la moindre de ses caractéristiques. Lorsque la biométrie n'est pas disponible, un code PIN peut la remplacer ; comme le PIN de Windows Hello, ce PIN n'est lui aussi vérifié que localement sur l'appareil, et ne circule jamais sur le réseau — une différence décisive avec le mot de passe.

Pourquoi les clés d'accès résistent-elles à l'hameçonnage ?

Parce que le mécanisme lui-même ne demande jamais à l'utilisateur de repérer un faux site. Une clé d'accès est créée en étant liée au domaine du site (le RP ID), et le navigateur ne propose que les clés d'accès correspondant au « domaine du site actuellement affiché ». Même en visitant un faux domaine parfaitement imité, la clé d'accès du vrai site n'apparaît jamais parmi les options, si bien que l'utilisateur ne peut tout simplement pas se faire tromper. De plus, la signature intègre le hachage de l'origine et du RP ID tels que vérifiés par le navigateur, donc même si la signature est relayée, la vérification côté serveur légitime la rejette. Le fait qu'un incident du type « saisir de véritables identifiants sur un faux site » soit structurellement impossible — contrairement au mot de passe ou au code SMS — constitue la différence fondamentale avec les mesures qui reposent sur la formation ou la vigilance des utilisateurs.

Si je perds mon smartphone, vais-je perdre l'accès à mon compte ?

Si votre clé d'accès est de type synchronisé (stockée dans le trousseau iCloud ou le gestionnaire de mots de passe Google), elle peut être restaurée sur un nouvel appareil connecté au même identifiant Apple ou compte Google. Cependant, la restauration d'un coffre-fort chiffré de bout en bout exige, au-delà du mot de passe du compte, une vérification d'identité supplémentaire — comme la saisie du verrouillage d'écran (code d'accès) de l'ancien appareil — de sorte que la perte de ces moyens de récupération peut elle aussi rendre la restauration impossible. Il est donc important de ne pas tout confier à un seul smartphone. Une clé d'accès liée à l'appareil (clé de sécurité, Windows Hello, etc.) partage le destin de cet appareil : la pratique standard consiste donc à enregistrer plusieurs clés d'accès pour les comptes importants. La plupart des services permettent d'enregistrer plusieurs clés d'accès sur un même compte. Notez que la procédure de désactivation en cas de perte diffère selon le type. Pour le type synchronisé, comme la copie sur chaque appareil constitue un seul et même identifiant, il faut d'abord, côté compte de la plateforme, supprimer l'appareil perdu ou lancer un effacement à distance pour rendre inutilisable la copie sur cet appareil (supprimer cette clé d'accès dans les paramètres du compte du service invalide en une seule fois toutes les copies sur tous les appareils). Pour le type lié à l'appareil, il suffit de supprimer côté service la clé d'accès de cet authentificateur pour ne désactiver que la clé perdue. Dans un cadre organisationnel, il est important de concevoir conjointement une « redondance permettant à l'utilisateur de se rétablir par lui-même » et une « procédure permettant à l'administrateur de révoquer en cas de perte ».

Les clés d'accès ont-elles aussi des faiblesses ?

Oui. Mais il serait plus exact de dire que l'emplacement de la faiblesse se déplace. Comme l'authentification elle-même se durcit grâce à la cryptographie à clé publique, les attaquants visent des zones périphériques plus faibles. Concrètement : si des moyens traditionnels comme le mot de passe ou le SMS coexistent encore, ils restent le maillon le plus faible ; il existe des techniques exploitant le flux de récupération de compte pour amener l'attaquant à enregistrer sa propre clé d'accès ; et pour le type synchronisé, le piratage du compte cloud lui-même devient un nouveau point de défaillance unique. Par ailleurs, une attaque visant à voler le cookie de session après la connexion n'est pas empêchée par la clé d'accès — les menaces sans rapport avec l'authentification ne disparaissent donc pas pour autant. Lors de la mise en œuvre, il ne suffit pas « d'ajouter » la clé d'accès : il faut aussi concevoir le renforcement du flux de récupération et la réduction planifiée des moyens de repli.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.