Pourquoi les passkeys sont-ils sûrs — Fonctionnement, synchronisation et précautions en cas de perte

« On peut se connecter avec son empreinte, donc c’est sûr. » Les passkeys sont parfois présentés ainsi, mais le cœur de leur sécurité n’est pas l’empreinte ni le visage. Il tient à prouver par une signature que l’on détient la clé de ce site, sans remettre la clé privée au service auquel on se connecte.¹

Cela dit, si l’on comprend « un passkey ne peut jamais être usurpé » ou « la clé privée ne quitte jamais le téléphone en aucune circonstance », on se trompera sur la synchronisation et sur la perte d’un appareil. Durcir le mécanisme de connexion est une chose ; le terminal, les moyens de récupération et la session après connexion devenant sûrs tout seuls en est une autre.

Cet article part de la différence avec les mots de passe, illustre les flux d’enregistrement et de connexion, puis enchaîne les raisons de la résistance à l’hameçonnage, la différence entre passkeys synchronisés et liés à l’appareil, et la conduite à tenir si l’on perd un terminal. La seconde moitié traite des points à vérifier pour les introduire dans un service web interne ou dans des systèmes métier Windows.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (38 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

1. Trois raisons pour lesquelles les passkeys sont sûrs

Un passkey est une information d’identification fondée sur la cryptographie à clé publique, utilisable pour se connecter à la place d’un mot de passe. De la paire de clés créée à l’enregistrement, la clé privée reste sous le contrôle de l’utilisateur et la clé publique est enregistrée auprès du service. Sur le Web, l’enregistrement et l’authentification utilisent une API standard appelée WebAuthn.¹²

flowchart TB
        accTitle: Trois faiblesses d'authentification que les passkeys changent
        accDescr: La remise d'un secret, la réutilisation d'une réponse et l'erreur sur le lieu d'usage sont chacune traitées par un mécanisme distinct.
        A["Connexion par passkey"] --> B["Renvoyer une signature, jamais la clé privée"]
        A --> C["Recouper le challenge et le consommer"]
        A --> D["Vérifier le RP ID et l'origine"]
        B --> E["La clé publique seule ne peut pas forger une signature"]
        C --> F["Une réponse antérieure ne peut pas être réutilisée"]
        D --> G["Inutilisable sur un faux site sans rapport"]

Figure 1 : La force d’un passkey vient de combiner la cryptographie, une demande à usage unique et une restriction du lieu d’usage.

Quand cet article dit que la clé privée « n’est pas envoyée », la destination visée est le serveur du service auquel on se connecte. Avec un passkey synchronisé, il existe un autre chemin qui stocke et duplique la clé privée sous forme chiffrée. Séparer les deux lève la question de ce que « ne jamais envoyer le secret » peut signifier lorsque la clé se synchronise vers le cloud.

Le serveur détient aussi plus que la clé publique : l’identifiant de l’information d’identification, sa correspondance avec un compte, les informations de session, etc. « La clé publique seule ne suffit pas à usurper une identité » et « la base de données n’a pas besoin d’être protégée » ne sont pas la même affirmation.²

2. Ce que les longs mots de passe et les codes à usage unique laissent subsister

Dans l’authentification par mot de passe ordinaire, le mot de passe saisi par l’utilisateur est envoyé au serveur sur une communication protégée par TLS, et le serveur le compare à un hachage stocké ou équivalent. Un hachage correctement salé, avec un coût de calcul suffisant, rend plus difficiles les attaques par essais répétés après une fuite des données stockées. Des mots de passe aléatoires, longs et non réutilisés ont aussi leur intérêt.³

Si le même mot de passe est réutilisé sur plusieurs services, le « credential stuffing » — essayer sur d’autres sites une paire identifiant/mot de passe fuitée d’un endroit — peut étendre les dégâts à d’autres comptes. Un mot de passe long n’empêche pas cette propagation s’il est réutilisé.⁴

Il reste pourtant ceci : le mot de passe correct peut encore être remis à la mauvaise partie. Si l’on saisit son vrai mot de passe sur un site préparé par l’attaquant, la valeur parvient à l’attaquant même lorsque le certificat TLS de ce site est valide. TLS n’a pas été brisé : on s’est trompé sur l’interlocuteur avec lequel on communique de façon sûre.

sequenceDiagram
        accTitle: La saisie sur un faux site n'est pas empêchée par TLS seul
        accDescr: Le mot de passe et le code saisis par l'utilisateur sur un faux site parviennent à l'opérateur de ce faux site même sur une communication chiffrée.
        participant U as Utilisateur
        participant P as Faux site
        participant S as Vrai service
        U->>P: Saisit le vrai mot de passe
        P->>S: Relaye le mot de passe saisi
        S-->>P: Demande une authentification supplémentaire
        P-->>U: Demande un code à usage unique
        U->>P: Saisit le code
        P->>S: Relaye le code tant qu'il est valide
        S-->>P: Émet une session si la vérification réussit

Figure 2 : Schéma de l’hameçonnage de type AiTM, qui relaye en temps réel le mot de passe et le code.

Le TOTP est un schéma dans lequel l’application d’authentification et le serveur détiennent une graine commune et génèrent un code selon l’heure. La graine elle-même n’est pas envoyée à chaque connexion. Mais le code saisi par l’utilisateur n’est pas lié au domaine du vrai site, si bien que, dans sa fenêtre de validité, un faux site peut le relayer. Les codes SMS ont le même problème : on peut les saisir sur un faux site.³

Cela ne signifie pas que l’authentification multifacteur est inutile. Elle bloque plus d’attaques que l’authentification par mot de passe seul. Par-dessus cela, face aux attaques qui visent la saisie manuelle d’un code, il y a une raison de passer à une authentification résistante à l’hameçonnage telle que FIDO/WebAuthn.⁵

Générer des mots de passe forts dans un gestionnaire et ne les remplir automatiquement que sur le bon domaine est aussi une mesure efficace. Mais on peut encore copier ce mot de passe et le coller dans un autre champ. Ce qui distingue un passkey, c’est que l’utilisateur ne peut pas, par ses seules actions, lever cette restriction du lieu d’usage.

3. Ce qui circule réellement à l’enregistrement et à la connexion

À l’enregistrement, on crée une paire de clés et on la lie au compte

Il y a trois grands rôles pour traiter un passkey : la RP (Relying Party) côté service, le navigateur et l’OS qui fournissent WebAuthn, et l’authentificateur qui génère et utilise la clé. Les authentificateurs comprennent ceux qui s’appuient sur des fonctions de l’OS et des gestionnaires d’informations d’identification, et les clés de sécurité FIDO2 externes. La comparaison du visage ou de l’empreinte est l’étape qui en autorise l’usage.²⁶

sequenceDiagram
        accTitle: Flux d'enregistrement d'un passkey
        accDescr: Une paire de clés est créée en réponse à la demande d'enregistrement, et le service vérifie la réponse d'enregistrement puis lie la clé publique et l'ID d'information d'identification au compte.
        participant S as Service
        participant B as Navigateur et OS
        participant A as Authentificateur
        S->>B: Challenge et informations de compte
        B->>B: Vérifie le lieu d'usage
        B->>A: Demande de création d'une information d'identification
        A->>A: Vérification de l'utilisateur et génération de la paire de clés
        A-->>B: Clé publique, ID d'information d'identification, etc.
        B->>S: Envoie la réponse d'enregistrement
        S->>S: Vérifie la réponse d'enregistrement
        S->>S: Enregistre l'information d'identification sur le compte

Figure 3 : Ce que l’on enregistre n’est pas seulement la clé publique, mais une réponse qui inclut un identifiant et des données de vérification. La clé privée n’est pas envoyée au service de connexion.

L’ID d’information d’identification (credential ID) est la valeur qui identifie quel passkey est en jeu. Le serveur la stocke en la faisant correspondre à la clé publique et au compte. Pour ajouter un nouveau passkey à un compte existant, on confirme d’abord par un moyen existant que l’on est bien l’utilisateur de ce compte, et on réauthentifie si nécessaire. On ne doit pas décider la cible d’enregistrement d’après le seul nom d’utilisateur envoyé par le navigateur.⁶⁷

En général, l’enregistrement auprès d’un autre service ou d’un autre compte crée une autre paire de clés, si bien que l’utilisateur n’a pas à pratiquer l’équivalent d’une réutilisation de mot de passe. Ce n’est toutefois pas un mécanisme qui empêche jusqu’au recoupement de l’utilisateur par d’autres informations comme une adresse e-mail, et cela ne signifie pas « un passkey rend anonyme ».

À la connexion, on renvoie une signature de la demande en cours

À la connexion, le serveur émet un challenge, un aléa difficile à prédire. L’authentificateur produit une signature avec la clé privée, et le navigateur la renvoie au serveur. Le serveur vérifie avec la clé publique enregistrée et s’assure qu’il s’agit d’une réponse correcte à la demande qu’il vient d’émettre.⁶

sequenceDiagram
        accTitle: Flux de connexion par passkey
        accDescr: L'authentificateur produit une signature liée à la demande en cours, et le serveur vérifie la signature, le challenge, le lieu d'usage et le compte.
        participant S as Service
        participant B as Navigateur et OS
        participant A as Authentificateur
        S->>B: Challenge non utilisé et RP ID
        B->>B: Vérifie la validité du lieu d'usage
        B->>A: Hachage du RP ID et des données
        A->>A: Confirme par biométrie ou PIN
        A->>A: Signe avec la clé privée
        A-->>B: Données d'authentificateur et signature
        B->>S: ID d'information d'identification et réponse d'authentification
        S->>S: Vérifie la réponse et le compte
        S-->>B: N'émet une session qu'en cas de succès

Figure 4 : La réponse de connexion est « la preuve que l’on détient la clé privée », pas la clé privée elle-même.

Plus précisément, les données signées à l’authentification sont les suivantes. || désigne la concaténation d’octets.⁸

données signées = authenticatorData || SHA-256(clientDataJSON)

clientDataJSON:
  type       webauthn.get pour une authentification
  challenge  challenge émis par le serveur
  origin     origine de l'appelant

authenticatorData:
  rpIdHash   hachage SHA-256 du RP ID
  flags      résultats de présence de l'utilisateur, de vérification de l'utilisateur, etc.
  signCount  compteur de signatures

« Signer le challenge » est une description abrégée pour saisir l’ensemble. En réalité, le lieu d’usage et l’état de l’authentificateur entrent aussi dans la vérification de la signature. Il est aussi important de retenir le partage des rôles : ce n’est pas l’authentificateur qui lit la page web pour juger l’origine, c’est le navigateur qui lui transmet le hachage des données client qu’il a rassemblées.

flowchart TB
        accTitle: Données liées à la signature à l'authentification
        accDescr: Le hachage des données client, qui incluent le challenge et l'origine, est concaténé aux données d'authentificateur, qui incluent le hachage du RP ID, puis signé.
        A["Challenge, origine, etc."] --> B["Hachage de clientDataJSON"]
        C["Hachage du RP ID, drapeaux, etc."] --> D["authenticatorData"]
        B --> E["Concaténer les données d'authentificateur et le hachage"]
        D --> E
        E --> F["Signer avec la clé privée"]

Figure 5 : Outre le challenge, le lieu d’usage et l’état de l’authentificateur interviennent dans la vérification de la signature.

Les signatures passées ne peuvent pas être réutilisées, non parce que la signature elle-même s’efface avec le temps. C’est parce que le serveur lie le challenge à la tentative de connexion, pose une échéance, et n’accepte plus une demande déjà utilisée. Réussir la vérification de signature par clé publique ne suffit pas, à elle seule, comme condition pour autoriser la connexion.

4. Pourquoi un faux site même très ressemblant ne peut pas l’utiliser

Le RP ID et l’origine n’ont pas le même rôle

Le RP ID est le nom de domaine qui fixe la portée de l’information d’identification ; on le spécifie d’ordinaire sous la forme example.com. L’origine, elle, est le triplet schéma-hôte-port. On peut par exemple avoir https://login.example.com comme origine et example.com comme RP ID.⁹

Dans la vérification habituelle par relation de domaines, une page de login.example.com peut spécifier example.com comme RP ID. En revanche, une page d’un examp1e.com sans rapport ne peut pas spécifier example.com pour utiliser le passkey du vrai site. Ce n’est pas la ressemblance visuelle qui compte : le navigateur vérifie la relation du lieu d’usage.

flowchart TB
        accTitle: Restriction du lieu d'usage des informations d'identification par le RP ID
        accDescr: Le jugement du navigateur diffère, pour une demande du vrai RP ID, entre une page en relation de domaine légitime et un faux site sans rapport.
        A["Spécifier example.com comme RP ID"] --> B{"D'où vient l'appel"}
        B -->|"login.example.com"| C["Les conditions de relation de domaine sont réunies"]
        B -->|"examp1e.com"| D["Domaine sans rapport, donc refus"]
        C --> E["Poursuivre l'authentification avec le passkey correspondant"]
        E --> F["Le serveur vérifie aussi s'il s'agit d'une origine autorisée"]
        D --> G["Le passkey du vrai site ne peut pas s'utiliser"]

Figure 6 : La restriction du lieu d’usage par le navigateur et la vérification d’origine par le serveur soutiennent toutes deux la résistance à l’hameçonnage.

Côté serveur aussi, on vérifie que l’origin renvoyé avec la signature est une origine déjà autorisée, et que rpIdHash est le hachage du RP ID attendu. On ne doit pas accepter, comme authentification du vrai compte, une clé créée sous le RP ID du faux site lui-même, ni une réponse d’une origine non autorisée.⁸

Par ailleurs, WebAuthn Level 3 prévoit aussi les Related Origin Requests, qui permettent d’utiliser le même RP ID sur une autre origine explicitement associée par le service. L’explication « si le nom d’hôte n’est pas une correspondance exacte, c’est toujours inutilisable » n’est pas exacte non plus. L’important est de fermer l’usage de l’information d’identification au périmètre reconnu par le service. Utiliser des origines liées n’est pas non plus une invitation à élargir sans limite la liste d’autorisation du serveur.⁹

La « résistance à l’hameçonnage » n’est pas une résistance à toutes les fraudes

Les explications qui précèdent supposent un navigateur, un OS et un authentificateur dignes de confiance, et un serveur qui effectue les vérifications nécessaires. WebAuthn à lui seul ne résout pas jusqu’à la compromission du vrai site, les logiciels malveillants sur le terminal, ou une procédure de récupération de compte trop faible.

On peut aussi se laisser entraîner par un faux site qui dit « le passkey ne fonctionne pas, saisissez le mot de passe et le code SMS » et emprunter un autre chemin de connexion. Un passkey est solide contre l’accident qui consiste à remettre la vraie information d’identification à un faux site ; cela ne signifie pas que l’utilisateur n’a plus jamais à faire attention.⁵

5. Empreinte, visage et PIN ne sont pas un mot de passe envoyé au serveur

Si l’on demande une empreinte ou un visage pour utiliser un passkey, c’est pour confirmer que l’opération d’usage de la clé privée est autorisée par l’utilisateur légitime de ce terminal. Ce traitement s’appelle vérification de l’utilisateur (User Verification, UV). Une réponse d’authentification WebAuthn n’embarque jamais une image d’empreinte ni un vecteur de caractéristiques faciales vers le service de connexion.¹²

flowchart TB
        accTitle: Confirmation d'identité sur le terminal et vérification de signature côté service
        accDescr: L'empreinte, le visage et le PIN servent, côté utilisateur, à autoriser l'usage de la clé ; le service vérifie non pas les données biométriques mais la signature et le résultat de vérification.
        A["Confirmer par empreinte, visage ou PIN"] --> B["L'authentificateur autorise l'usage de la clé privée"]
        B --> C["Créer une réponse d'authentification signée"]
        C --> D["Le service vérifie avec la clé publique"]
        D --> E["Confirmer aussi le résultat de la vérification de l'utilisateur demandée"]

Figure 7 : Le déverrouillage du terminal et l’authentification auprès du service sont liés, mais le serveur ne compare ni l’empreinte ni le PIN.

On peut avoir l’impression que, s’il s’utilise avec un PIN, c’est comme un mot de passe. La différence est ce à quoi ce PIN est comparé. Ici, le PIN sert à autoriser l’usage de l’authentificateur ; ce n’est pas un mot de passe que le site web détient pour tous les utilisateurs et reçoit à chaque connexion. Sur un authentificateur approprié, des limites au nombre d’erreurs de saisie s’appliquent aussi.³

Cela dit, si le terminal est volé et que la méthode de déverrouillage est connue, le risque qu’un attaquant utilise le passkey augmente. Passer à la reconnaissance faciale ne justifie pas un code d’accès trop simple. De plus, la présence de l’utilisateur (User Presence, UP), qui indique par exemple un toucher de l’écran, et l’UV par biométrie ou PIN sont des drapeaux distincts. Côté implémentation, on exige l’UV nécessaire et on la confirme aussi dans la réponse.

6. Types synchronisé et lié à l’appareil : ce que l’on protège n’est pas le même endroit

Il existe des passkeys synchronisés entre appareils et des passkeys liés à un authentificateur précis. Les deux authentifient sans remettre la clé privée au service de connexion, mais les méthodes de conservation, de duplication et de restauration de la clé diffèrent.¹⁰

flowchart TB
        accTitle: La synchronisation et la connexion sont des chemins distincts
        accDescr: Le type synchronisé duplique la clé via un coffre chiffré, mais ce que le type synchronisé comme le type lié envoient au service de connexion, c'est une réponse d'authentification.
        V["Coffre de synchronisation chiffré"] <-->|"synchronisation / restauration"| A["Passkey synchronisé du terminal A"]
        V <-->|"synchronisation / restauration"| B["Le même passkey du terminal B"]
        A -->|"réponse signée"| S["Service de connexion"]
        B -->|"réponse signée"| S
        K["Authentificateur lié à l'appareil"] -->|"réponse signée"| S

Figure 8 : Séparer le chemin de synchronisation qui duplique la clé privée et le chemin de connexion au service permet de comprendre la différence.

Dans les mécanismes d’Apple et de Google, les passkeys synchronisés sont protégés par un chiffrement de bout en bout. Ce n’est pas une conception où le fournisseur de service pourrait lire telles quelles les données stockées dans le cloud pour obtenir la clé privée.¹¹¹²

En revanche, pour restaurer sur un nouvel appareil, il peut falloir, en plus de la connexion au compte de synchronisation, le verrouillage d’écran de l’ancien appareil ou le PIN du coffre. Les conditions concrètes varient selon le produit et les réglages. On ne peut dire ni « le mot de passe du compte cloud suffit à restaurer tous les passkeys », ni « dès que le compte cloud est récupéré, la restauration est garantie ».¹¹¹³

Avec le type synchronisé, si les moyens de déverrouillage et de récupération du coffre, ainsi que les appareils participants, sont compromis, l’impact peut s’étendre à plusieurs services. L’authentification multifacteur du compte de synchronisation, un verrouillage fort du terminal et la gestion des destinations de récupération sont importants. Si le service le permet, on envisage aussi une protection par clé de sécurité physique. Mais si la clé de récupération elle-même n’est placée que sur le même terminal ou dans le même coffre, on se retrouve dans une configuration où tout se perd ensemble.

Il faut aussi veiller au niveau d’assurance de l’organisation. Dans NIST SP 800-63B-4, un authentificateur synchronisable peut servir en AAL2 si les conditions sont réunies, mais pas en AAL3, qui n’admet pas l’export de la clé privée. Inversement, un type lié à l’appareil ne devient pas automatiquement AAL3 : il faut encore satisfaire le reste des exigences, notamment la protection matérielle.¹⁴¹⁵

Utiliser un smartphone via un QR code n’est pas de la synchronisation

Il existe aussi une méthode où l’on scanne avec le smartphone un QR code affiché sur le PC, puis on se connecte avec le passkey de ce smartphone. Dans l’authentification inter-appareils FIDO, la proximité est confirmée par Bluetooth ou similaire, et l’authentification se fait côté smartphone. Ce n’est pas une opération qui copie la clé privée du smartphone vers le PC.¹⁶¹

flowchart TB
        accTitle: Flux pour se connecter à un autre PC avec la clé du smartphone
        accDescr: On scanne le QR du PC avec le smartphone, on confirme la proximité et on authentifie par vérification de l'utilisateur sur le smartphone. Ce n'est pas un flux qui copie la clé privée vers le PC.
        A["Afficher un QR sur l'écran de connexion du PC"] --> B["Scanner le QR avec le smartphone"]
        B --> C["Confirmer la proximité entre les appareils"]
        C --> D["Vérification de l'utilisateur et signature sur le smartphone"]
        D --> E["Le service vérifie la réponse d'authentification"]
        E --> F["La connexion s'établit sur le PC"]

Figure 9 : L’authentification inter-appareils utilise le smartphone que l’on a sous la main comme authentificateur, et ne duplique pas la clé sur le PC.

Cela peut s’utiliser même depuis un PC qui n’est pas la même destination de synchronisation, mais cela ne constitue pas une réserve si l’on perd le smartphone qui détient la clé. Distinguez « j’ai pu me connecter depuis le PC » et « un passkey indépendant est aussi enregistré sur le PC ».

7. En cas de perte du smartphone, arrêtez séparément le terminal, l’information d’identification et la session

En cas de perte, organisez depuis un terminal sûr un verrouillage à distance et, si un usage abusif est soupçonné, contactez rapidement le service ou le point de contact de l’organisation. En parallèle, vérifiez si un passkey de secours ou un moyen de récupération permet d’entrer dans le compte. Il n’est pas nécessaire d’attendre la fin de la restauration pour signaler la perte ou suspendre l’usage. La protection du terminal, celle du compte de synchronisation et la révocation côté service n’ont pas le même rôle.¹⁷¹⁸

flowchart TB
        accTitle: Ce qu'il faut vérifier séparément en cas de perte du terminal
        accDescr: On avance la protection du terminal perdu et le contact du point d'accueil tout en confirmant un moyen de récupération sûr. La révocation du passkey et la fin des sessions existantes se font séparément.
        A["Terminal perdu"] --> B["Verrouillage à distance, etc., et contact du point d'accueil"]
        A --> C["Vérifier les clés de secours et les moyens de récupération"]
        B --> D["Arrêter l'usage des passkeys à risque"]
        C --> E["Entrer dans l'écran de gestion depuis un terminal sûr"]
        D --> F["Terminer aussi les sessions existantes à part"]
        E --> F
        F --> G["Vérifier les destinations de synchronisation et les méthodes d'authentification enregistrées"]
        G --> H["Préparer une nouvelle clé et une réserve dans un environnement sûr"]

Figure 10 : Arrêter le terminal, révoquer le passkey et terminer l’état déjà connecté sont des traitements distincts.

Avec le type lié à l’appareil, on peut séparer : révoquer côté service l’information d’identification de l’authentificateur perdu, et utiliser une information d’identification de secours enregistrée à part. Avec le type synchronisé, les copies sur plusieurs appareils sont, du point de vue du service, la même information d’identification, si bien que supprimer cette information d’identification côté service empêche aussi les copies des autres appareils de se connecter à ce même service. On ne peut pas toujours révoquer individuellement, depuis le service, la seule copie d’un appareil.¹⁰²

Un effacement à distance n’est pas non plus forcément répercuté immédiatement si le terminal est hors ligne. Avec « Localiser » d’Apple, l’effacement d’un terminal hors ligne commence à la prochaine mise en ligne.¹⁹ Juger, du seul fait d’avoir retiré le terminal du compte de synchronisation, que la copie de la clé privée sur ce terminal est devenue inutilisable est dangereux. S’il y a un risque d’abus, il faut décider d’arrêter et de révoquer rapidement l’information d’identification concernée auprès de chaque service. Si l’on ne peut pas se connecter, on utilise le point de contact officiel, et on vérifie en parallèle la procédure qui permettra à l’utilisateur légitime de revenir.

De plus, supprimer un passkey ne termine pas forcément toutes les sessions existantes. Vérifiez à part une fonction du type « se déconnecter de tous les appareils », et contrôlez aussi qu’aucun passkey ni destination de récupération suspects n’ont été ajoutés.²⁰¹⁸

Avant une perte, il est rassurant de vérifier si les services importants acceptent l’enregistrement de plusieurs passkeys, d’enregistrer une réserve indépendante, et de tester que l’on peut réellement s’y connecter. Avoir la même clé sur deux appareils par synchronisation est pratique, mais ce n’est pas la même chose qu’avoir enregistré une autre clé. Avant de supprimer le dernier moyen de connexion, vérifiez les moyens de revenir, y compris l’emplacement des codes de récupération.

8. Où restent les faiblesses, même avec un passkey

Un passkey durcit une partie importante de l’authentification, mais le chemin vers le compte n’est pas seulement l’écran de connexion habituel. À l’introduction, outre « le nombre de personnes qui utilisent un passkey a-t-il augmenté », inspectez les chemins suivants.

flowchart TB
        accTitle: Chemins d'attaque qui restent après l'introduction des passkeys
        accDescr: Indépendamment de la connexion par passkey, les moyens de repli trop faibles, la procédure de récupération, le terminal ou le coffre, et les sessions existantes restent des cibles.
        B["Connexion de repli trop faible"] --> A["Accès illégitime au compte"]
        C["Abus de la procédure de récupération"] --> A
        D["Compromission du terminal ou du coffre"] --> A
        E["Abus de session"] --> A

Figure 11 : Même si la connexion par passkey habituelle est forte, les autres entrées et l’état après connexion doivent être protégés séparément.

Connexions de repli. Si les mêmes opérations sont possibles avec le seul mot de passe ou le SMS, l’attaquant visera ceux-là. Cela dit, les désactiver en masse avant d’avoir confirmé les réserves et la restauration exclut aussi les utilisateurs légitimes. Mettez en place les appareils pris en charge, les clés de secours et la procédure de support, puis réduisez progressivement, en ciblant.⁵

Récupération de compte et ajout de clés. Si l’on relâche la confirmation d’identité sur le seul signalement « le terminal est cassé », cela devient un chemin pour faire enregistrer le passkey de l’attaquant lui-même. Pour les comptes importants, combinez la confirmation des demandes de récupération, une réauthentification lors de l’ajout ou de la suppression d’une méthode d’authentification, les notifications de changement et l’audit. Émettre une notification ne suffit pas à empêcher un enregistrement non autorisé : il faut une confirmation avant l’enregistrement.¹⁸

Terminal et coffre de synchronisation. Les mises à jour de l’OS et du navigateur, le verrouillage du terminal et la connaissance des appareils participants au coffre restent nécessaires. Un passkey n’est pas une fonction qui transforme un PC peu sûr en PC sûr. Sur un terminal partagé, vérifiez aussi qui peut utiliser l’information d’identification.

Session. Si un cookie de session ordinaire est volé et utilisable, l’attaquant peut parfois agir sans nouvelle authentification par passkey. Concevez à part Secure, HttpOnly, un SameSite approprié, la durée de validité, la réauthentification et la révocation côté serveur. HttpOnly limite la lecture du cookie par JavaScript, mais n’empêche pas jusqu’à l’abus d’opérations déjà connectées via XSS.²⁰

9. Points clés pour l’introduire dans un service web interne

Appeler l’API ne suffit pas à terminer l’implémentation de la connexion

L’API d’enregistrement WebAuthn est navigator.credentials.create(), l’API d’authentification navigator.credentials.get(). FIDO2 se compose de WebAuthn et de CTAP ; CTAP est la spécification par laquelle le client dialogue avec un authentificateur tel qu’une clé de sécurité externe. L’implémenteur d’un service web n’a pas à reconstruire lui-même jusqu’à la communication USB ou Bluetooth.²¹

flowchart TB
        accTitle: Répartition de l'implémentation des passkeys dans un service web
        accDescr: Le serveur émet les demandes et vérifie les réponses, le navigateur fournit l'API, et l'authentificateur utilise la clé.
        S["Serveur : émission des demandes et vérification des réponses"] <-->|"demande et réponse"| B["Navigateur : API WebAuthn"]
        B <--> O["Liaison avec l'OS ou le gestionnaire d'informations d'identification"]
        B <-->|"CTAP, etc."| A["Authentificateur externe"]

Figure 12 : On implémente ensemble l’appel côté navigateur et la vérification et la gestion de compte côté serveur.

Voici le squelette côté navigateur qui montre où passer les valeurs à l’API. Ce fragment à lui seul ne termine ni l’enregistrement ni la connexion. registrationOptions et authenticationOptions sont des valeurs créées par le serveur pour la tentative en cours, et les éléments binaires tels que challenge, user.id et l’ID d’information d’identification sont déjà convertis en séquence d’octets appropriée, et non laissés en chaîne Base64URL du JSON.²

// Appeler depuis l'action du bouton d'enregistrement. Les options sont émises et conservées par le serveur.
async function createPasskey(registrationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("Les passkeys ne sont pas utilisables dans cet environnement.");
  }
  const credential = await navigator.credentials.create({
    publicKey: registrationOptions,
  });
  if (!credential) throw new Error("L'enregistrement du passkey n'a pas abouti.");
  return credential;
  // Côté appelant, sérialiser la réponse d'enregistrement et l'envoyer au serveur.
  // Ne pas afficher l'enregistrement comme terminé tant que la vérification serveur n'a pas réussi.
}

// Flux d'authentification habituel, à appeler depuis l'action du bouton de connexion.
async function usePasskey(authenticationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("Les passkeys ne sont pas utilisables dans cet environnement.");
  }
  const assertion = await navigator.credentials.get({
    publicKey: authenticationOptions,
  });
  if (!assertion) throw new Error("L'authentification par passkey n'a pas abouti.");
  return assertion;
  // Côté appelant, sérialiser la réponse d'authentification et l'envoyer au serveur.
  // Le serveur vérifie et ne crée une session qu'en cas de succès.
}

Sur l’écran réel, le côté appelant traite la Promise rejetée et oriente l’utilisateur en cas d’annulation, de délai dépassé ou d’environnement non pris en charge. Pour la conversion binaire des réponses d’enregistrement et les communications, utiliser l’API correspondante de la bibliothèque retenue réduit les oublis d’implémentation.

authenticatorSelection.residentKey: "required" dans les options d’enregistrement est le réglage qui exige une information d’identification découvrable, utilisable en choisissant un compte. Dans une conception qui rend obligatoire la confirmation par biométrie ou PIN, on spécifie authenticatorSelection.userVerification: "required" à l’enregistrement et userVerification: "required" à l’authentification. user.id est un identifiant opaque d’au plus 64 octets émis par le serveur ; on n’utilise pas l’adresse e-mail elle-même, et on le distingue du nom affiché.⁷

Si l’on utilise l’interface conditionnelle (Conditional UI) pour proposer des suggestions de remplissage automatique dans le champ de connexion, on vérifie la prise en charge avec PublicKeyCredential.isConditionalMediationAvailable() et on combine mediation: "conditional" avec autocomplete="username webauthn" sur le champ. Pour les environnements non pris en charge, on conserve le flux habituel depuis un bouton, comme ci-dessus.²²

Concevoir d’abord les points que le serveur vérifie

Pour la vérification de la partie cryptographique, on peut utiliser une bibliothèque telle que SimpleWebAuthn sous Node.js ou fido2-net-lib sous .NET. Cela dit, disposer d’une bibliothèque ne rend pas automatiquement sûrs jusqu’à la liaison au compte et la conception de la récupération.²³²⁴

Ce tableau est un ensemble de points de contrôle d’implémentation, pas un substitut à la procédure de vérification de la spécification. Si l’on utilise une iframe ou des origines liées, on vérifie aussi ces conditions supplémentaires. Dans une authentification explicite habituelle, on confirme l’UP, et si l’UV est obligatoire, on confirme aussi l’UV de la réponse.⁷⁸

flowchart TB
        accTitle: Décision d'authentification côté serveur
        accDescr: On n'émet une session qu'après avoir confirmé la correspondance avec la demande en cours, le lieu d'usage, le titulaire de l'information d'identification, la signature et la stratégie.
        A["Réception de la réponse d'authentification"] --> B{"Correspond-elle à la demande non utilisée en cours"}
        B -->|"Oui"| C{"Le lieu d'usage et le compte titulaire sont-ils corrects"}
        C -->|"Oui"| D{"La signature et les résultats de vérification nécessaires sont-ils corrects"}
        D -->|"Oui"| E["Consommer la demande une seule fois et émettre une session"]
        B -->|"Non"| X["Refuser l'authentification"]
        C -->|"Non"| X
        D -->|"Non"| X

Figure 13 : Confirmez à la fois que la signature est correcte et que, cette fois, on peut autoriser la connexion à ce compte.

signCount n’est pas non plus un détecteur de clones universel. Il existe des authentificateurs sans compteur qui renvoient 0, et d’autres raisons qu’une duplication pour qu’une valeur n’augmente pas de façon monotone. Vérifiez le traitement dans les environnements adoptés, type synchronisé compris, et dans la bibliothèque, et utilisez les valeurs anormales comme entrée d’une décision de risque. Évitez les jugements uniformes du type « inférieur ou égal à la précédente = forcément un clone » ou « 0 = sûr ».⁸

Dans un environnement de vérification, distinguez l’exigence de contexte sécurisé de WebAuthn et l’exigence de RP ID. En général, HTTPS est nécessaire, et http://localhost peut servir au développement. Que http://127.0.0.1 soit traité comme origine potentiellement digne de confiance est une chose distincte de la possibilité d’utiliser une adresse IP comme RP ID. Comme le RP ID de WebAuthn a des conditions de nom de domaine, vérifiez aussi en développement avec une configuration que le navigateur utilisé accepte, telle que localhost. On ne peut pas emporter telles quelles vers le domaine de production les informations d’identification créées là.⁹²⁵

10. Que vérifier sous Windows et dans les systèmes internes

Sous Windows, l’important est de ne pas conclure, de la seule observation « l’écran Windows Hello est apparu », à l’emplacement de stockage du passkey ni à la présence d’une synchronisation. La vérification de l’utilisateur par Windows Hello, et le stockage et la synchronisation auprès d’un gestionnaire d’informations d’identification Microsoft ou d’un autre éditeur, sont des points à vérifier séparément. Il y a des passkeys stockés localement et des passkeys stockés chez un fournisseur de synchronisation.²⁶

flowchart TB
        accTitle: Ordre de vérification pour introduire des passkeys sous Windows
        accDescr: Distinguer dans l'ordre la cible de connexion, l'emplacement de stockage de l'information d'identification, la stratégie d'autorisation de l'organisation et la récupération en cas de perte.
        A["À quoi se connecte-t-on"] --> B["Distinguer service web, Entra ID et Windows"]
        B --> C["Vérifier l'emplacement de stockage du passkey et la présence d'une synchronisation"]
        C --> D["Vérifier la stratégie des méthodes d'authentification et la force d'authentification"]
        D --> E["Tester les clés de secours et la procédure en cas de perte"]

Figure 14 : Le même écran Windows Hello n’a pas le même sens opérationnel selon la cible de connexion et l’emplacement de stockage.

Les informations d’identification conservées dans le conteneur local de Windows Hello ne sont pas le même que le coffre synchronisé. Dans une configuration Windows Hello qui utilise le TPM, la protection de la clé par le TPM joue un rôle important. Cela dit, n’identifiez pas la classification générale des passkeys à la présence d’un TPM ; jugez d’après l’emplacement réel, le terminal et les exigences de l’organisation.²⁷²⁸

Dans Microsoft Entra ID, concevez séparément la stratégie des méthodes d’authentification qui autorise l’usage des passkeys, et la force d’authentification de l’accès conditionnel, qui décide de la force d’authentification exigée pour une ressource donnée. Le seul fait de permettre l’enregistrement d’un passkey ne restreint pas automatiquement tous les accès à une MFA résistante à l’hameçonnage. Les types de passkeys autorisés, type synchronisé compris, se confirment d’après l’état actuel de prise en charge et la stratégie de l’organisation.²⁹

Si vous rendez une application web interne directement compatible WebAuthn, mettez d’abord en place HTTPS, les certificats, la résolution de noms et un nom de domaine qui servira de RP ID stable. Si vous déléguez le traitement à une plateforme d’identité, le côté application conçoit la liaison avec cette plateforme et la gestion de session. Utiliser Entra ID depuis une application WinForms/WPF, et faire de l’application elle-même une RP WebAuthn, ne sont pas non plus la même chose.

De plus, un passkey n’est pas une fonction qui remplace automatiquement l’authentification vers un partage SMB, ni qui corrige directement les problèmes NTLM ou Kerberos. Décider quelle connexion on change, et d’abord essayer l’enregistrement, l’authentification, la perte et la récupération sur un petit périmètre, est ce qui mène à une introduction qui n’arrête pas l’activité.

11. Résumé — Ne pas remettre le secret et protéger le pourtour vont ensemble

La force d’un passkey tient à authentifier par une signature liée à la demande en cours et au lieu d’usage, sans remettre la clé privée au service auquel on se connecte. La seule fuite de la clé publique ne permet pas de produire une signature valide, et l’on ne peut pas non plus utiliser depuis un faux site sans rapport l’information d’identification destinée au vrai site.

En même temps, le coffre synchronisé, le verrouillage du terminal, les connexions de repli, la procédure de récupération et la session après connexion doivent continuer d’être protégés. Séparer les mesures que le passage aux passkeys rend inutiles de celles qui restent nécessaires est le point de vue qui permet d’évaluer correctement une introduction.

Côté utilisateur, vérifier l’emplacement de stockage et les moyens de récupération, et prévoir une réserve indépendante pour les comptes importants. Côté introduction, concevoir la vérification serveur, la gestion de plusieurs passkeys, et la révocation et la récupération comme une seule fonction. C’est en allant jusque-là que l’on relie commodité et résistance à l’hameçonnage à une exploitation réelle.

Articles connexes

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

Domaines de conseil associés

KomuraSoft LLC prend en charge le développement logiciel sur mesure, y compris la révision des fonctions d’authentification des systèmes web internes, la liaison avec Entra ID, et l’intégration de l’authentification dans des applications métier Windows telles que WinForms et WPF. Lorsque vous envisagez la prise en charge des passkeys, nous organisons ensemble non seulement l’écran de connexion, mais aussi les terminaux utilisés, la plateforme d’authentification existante et les procédures de récupération.

Références

Les spécifications et les informations produit ont été vérifiées au 8 septembre 2026. Les fonctions disponibles varient selon le navigateur, l’OS et les paramètres du locataire.

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.

Pourquoi un passkey est-il plus sûr qu'un mot de passe ?

Parce qu'il authentifie par une signature liée au challenge en cours et au site d'utilisation, sans jamais remettre la clé privée au service auquel on se connecte. La seule fuite de la clé publique ne permet pas à un attaquant de forger une signature, et un passkey destiné au vrai site ne peut pas s'utiliser depuis un faux site sans rapport. Il faut toutefois que le serveur fasse la vérification appropriée, et que le terminal, les moyens de récupération et la session restent protégés.

Les données d'empreinte ou de visage sont-elles envoyées au site ?

Une réponse d'authentification WebAuthn n'embarque jamais une image d'empreinte ni un vecteur de caractéristiques faciales vers le service auquel on se connecte. La biométrie et le PIN servent, côté utilisateur, à autoriser l'usage de la clé privée ; le service vérifie la signature et le résultat de la vérification de l'utilisateur.

Si la clé privée n'est jamais envoyée, comment un passkey peut-il se synchroniser ?

Parce que l'authentification auprès du service et la synchronisation par le gestionnaire d'informations d'identification sont deux chemins distincts. Un passkey synchronisé chiffre la clé privée et la duplique entre appareils, ce qui n'est pas la même chose que de remettre la clé privée au service auquel on se connecte. Les conditions de déverrouillage et de restauration du coffre de synchronisation varient selon le produit et la configuration.

Que deviennent les comptes qui utilisent des passkeys si je perds mon smartphone ?

Avec un passkey synchronisé, vous pourrez parfois l'utiliser sur un autre appareil une fois les conditions de récupération du coffre réunies ; avec un passkey lié à l'appareil, il faut une information d'identification de secours enregistrée à part ou un moyen de récupération. Pendant que vous sécurisez le terminal et signalez la perte, vérifiez que vous avez un moyen sûr de récupérer, et traitez la révocation de l'information d'identification à risque et la fin des sessions existantes comme deux étapes distinctes. Si le service révoque la même information d'identification synchronisée, les copies sur vos autres appareils ne peuvent plus se connecter à ce service non plus.

Les passkeys rendent-ils inutiles les mesures anti-hameçonnage ?

Non. Les passkeys sont solides contre la remise d'informations d'identification à un faux domaine, mais se laisser entraîner vers un mot de passe ou un SMS, l'abus de la procédure de récupération, et la compromission du terminal ou de la session exigent chacun leurs propres contre-mesures.

Un passkey utilisé avec Windows Hello est-il forcément lié à l'appareil ?

L'écran Windows Hello à lui seul ne dit pas où l'information d'identification est stockée ni si elle se synchronise. Distinguez les informations d'identification du conteneur local des passkeys enregistrés chez un fournisseur de synchronisation, et vérifiez l'emplacement réel, le terminal et la stratégie de l'organisation.

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.