Passkeys, FIDO2 et WebAuthn : se connecter sans mot de passe

Une passkey (en français « clé d'accès ») est un identifiant de connexion qui remplace le mot de passe par une paire de clés cryptographiques : la clé privée reste sur ton appareil, le site ne garde que la clé publique. Pour te connecter, ton appareil signe un défi envoyé par le site, après que tu l'as déverrouillé avec ton empreinte, ton visage ou un code PIN. Les passkeys reposent sur les normes FIDO2 et WebAuthn ; elles résistent à l'hameçonnage, ce qu'aucun mot de passe ni code à usage unique ne fait.

Pourquoi se passer du mot de passe

Le mot de passe a trois défauts que la MFA atténue sans les supprimer :

• c'est un secret partagé : le serveur en garde une empreinte, qui peut fuiter et être cassée (chapitre 4) ;
• il se réutilise : le même mot de passe ouvre souvent plusieurs sites, et une fuite sur l'un compromet les autres (credential stuffing) ;
• il se saisit n'importe où : rien n'empêche l'utilisateur de le taper sur un faux site qui imite le vrai.

Une passkey règle les trois d'un coup. Le serveur ne stocke qu'une clé publique, inutile à un voleur. Chaque site reçoit une paire de clés différente. Et la clé privée ne signe que pour le nom de domaine pour lequel elle a été créée : sur sorbier-logistique-connexion.example, la passkey de sorbier.example ne répond tout simplement pas.

FIDO2, WebAuthn, CTAP : qui fait quoi

L'authentificateur est le composant qui détient la clé privée. Il en existe deux familles :

• les authentificateurs de plateforme, intégrés à l'appareil : Windows Hello (avec le TPM du PC), Touch ID et Face ID sur Apple, le déverrouillage d'Android ;
• les authentificateurs itinérants : une clé de sécurité USB ou NFC que l'on branche sur n'importe quel poste.

Passkeys synchronisées ou liées à un appareil

Une passkey peut rester dans un seul appareil, ou être copiée de façon chiffrée entre tes appareils par ton trousseau (iCloud, gestionnaire de mots de passe de Google, gestionnaire de mots de passe tiers).

Une entreprise peut exiger des authentificateurs précis grâce à l'attestation : à la création, l'authentificateur peut fournir un certificat de son fabricant qui prouve son modèle. Microsoft Entra ID permet ainsi de n'autoriser que certaines clés de sécurité pour les administrateurs.

L'enregistrement et la connexion, pas à pas

Le W3C appelle ces deux échanges des cérémonies.

L'enregistrement (création de la passkey), une fois par appareil :

1. l'utilisateur, déjà authentifié (ou en cours d'inscription), clique sur « Créer une passkey » ;
2. le serveur envoie un défi aléatoire, l'identifiant du site (relying party ID, par exemple sorbier.example) et un identifiant opaque de l'utilisateur ;
3. le navigateur vérifie que la page est bien servie par ce domaine, puis transmet la demande à l'authentificateur ;
4. l'utilisateur se vérifie localement (empreinte, visage, PIN) ;
5. l'authentificateur génère une nouvelle paire de clés pour ce site, garde la clé privée et renvoie la clé publique avec un identifiant de clé (credential ID) ;
6. le serveur vérifie la réponse et enregistre la clé publique pour ce compte.

La connexion, à chaque fois :

Le défi change à chaque connexion : une signature interceptée ne peut pas être rejouée. L'empreinte digitale ou le visage ne quittent jamais l'appareil : ils servent seulement à autoriser l'usage de la clé privée.

Côté SLAM : ce que l'application stocke et vérifie

Pour chaque passkey d'un utilisateur, la base de l'application garde quelques colonnes :

Côté navigateur, l'appel à WebAuthn ressemble à ceci (simplifié : les champs binaires arrivent du serveur encodés et doivent être convertis en ArrayBuffer) :

// Connexion : le serveur a fourni un défi aléatoire à usage unique
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: defiRecuDuServeur,      // ArrayBuffer, au moins 16 octets aléatoires
    rpId: 'sorbier.example',           // le domaine du site
    userVerification: 'required',      // empreinte, visage ou PIN exigés
    timeout: 60000,
  },
});
// On renvoie au serveur : assertion.id, la signature et les données signées
await fetch('/api/passkeys/verifier', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(serialiser(assertion)),   // fonction de conversion en base64url
});

Le serveur, lui, ne vérifie pas la signature à la main : il utilise une bibliothèque maintenue (il en existe pour Node.js, PHP, Java, C# et Python). Elle contrôle que le défi est celui qu'il a émis, que l'origine est la bonne, que l'utilisateur a été vérifié, puis vérifie la signature avec la clé publique enregistrée.

Côté SISR : les passkeys dans l'entreprise

Dans un parc Windows, Antoine Mercier, responsable informatique de Sorbier Logistique, dispose de trois options :

• Windows Hello for Business : chaque poste crée une clé liée à son TPM, déverrouillée par PIN ou biométrie. Le salarié n'utilise plus son mot de passe au quotidien ;
• les passkeys dans Microsoft Entra ID : sur une application d'authentification ou sur une clé de sécurité, pour se connecter aux services Microsoft 365 et aux applications fédérées (chapitre 6) ;
• les clés de sécurité FIDO2 pour les administrateurs, avec une politique qui interdit les autres méthodes sur ces comptes.

Le plus difficile n'est pas technique : il faut organiser l'enrôlement (remettre les clés, vérifier l'identité de la personne au moment où elle crée sa passkey) et la récupération en cas de perte. Une procédure de secours qui revient au mot de passe seul recrée la faiblesse qu'on voulait supprimer.

Les limites à connaître

• La récupération : un compte protégé uniquement par une passkey liée à un appareil perdu est inaccessible. Il faut au moins deux authentificateurs, ou une procédure de vérification d'identité.
• La compatibilité : les systèmes et navigateurs récents gèrent tous WebAuthn, mais un vieux poste ou une application métier ancienne peut ne pas le permettre.
• La transition : tant que le mot de passe reste accepté en parallèle, l'attaquant peut toujours tenter de le voler. Le bénéfice complet arrive quand le mot de passe est désactivé pour le compte.
• L'appareil déverrouillé : une passkey synchronisée protège mal si l'appareil n'a pas de verrouillage ou si le compte de synchronisation est lui-même mal protégé.

Comment l'E7 l'interroge

Les passkeys sont récentes et peu de sujets officiels les ont encore citées par leur nom. Mais elles sont la bonne réponse dès qu'un sujet demande une authentification résistante à l'hameçonnage, une alternative au mot de passe pour des comptes sensibles, ou la façon de stocker un moyen d'authentification sans risque en cas de fuite de la base.

• SLAM : expliquer pourquoi la fuite de la table des clés publiques n'est pas grave ; dire ce que le serveur doit vérifier dans une réponse WebAuthn ; comparer passkey et mot de passe haché.
• SISR : proposer une authentification des administrateurs qui résiste à l'hameçonnage ; expliquer l'intérêt d'avoir deux clés de sécurité par administrateur.

Pour aller plus loin. Une passkey est une paire de clés asymétriques : le principe de la clé publique et de la clé privée est expliqué dans le chapitre Chiffrement asymétrique du cours Cryptographie.

Exercices