WebAuthn : Web Authentication
Sécurité
Norme du W3C qui permet à un site web d'authentifier un utilisateur par cryptographie à clé publique plutôt que par mot de passe. Le navigateur relaie un défi entre le site et un authentificateur (clé de sécurité, téléphone, puce de l'ordinateur) qui le signe sans jamais livrer sa clé privée.
Une paire de clés par site : À l'enregistrement, l'authentificateur génère une paire de clés propre à ce site et ne transmet que la clé publique. Le serveur ne stocke donc aucun secret : une fuite de sa base livre des clés publiques, ce qui fait un butin assez décevant.
Résistance au hameçonnage : Le navigateur lie chaque signature à l'origine réelle de la page, et l'authentificateur refuse de signer pour un domaine qui n'est pas le bon. Un mot de passe se tape volontiers sur un faux site au bout d'un mail bien tourné ; une clé WebAuthn, elle, refuse tout net, ce qu'aucune campagne de sensibilisation n'a jamais obtenu d'un humain.
Deux familles d'authentificateurs : Les authentificateurs de plateforme sont intégrés à l'appareil (puce TPM, enclave sécurisée d'un téléphone). Les authentificateurs itinérants se branchent ou s'approchent (clé USB, NFC, Bluetooth) et parlent au navigateur via le protocole CTAP.
Vérification de l'utilisateur : Avant de signer, l'authentificateur peut exiger une empreinte, un visage ou un code local. Ce geste reste sur l'appareil : le serveur reçoit seulement l'indication que la vérification a eu lieu.
Ce qui arrive si on s'en passe
Sans WebAuthn, l'authentification repose sur un secret partagé : le mot de passe que l'utilisateur saisit et dont le serveur conserve une empreinte. Rien ne lie ce secret au domaine légitime, si bien qu'il peut être tapé sur une page qui imite le site ; un proxy d'hameçonnage relaie alors en temps réel le mot de passe, et même un code à usage unique. Une fuite de la base expose des empreintes attaquables hors ligne, alors qu'une base de clés publiques n'apprendrait rien d'exploitable à l'attaquant. Un mot de passe réutilisé ailleurs ouvre la porte au bourrage d'identifiants, et les essais en ligne (force brute, pulvérisation de mots de passe) restent possibles contre chaque compte. Enfin, la connexion ne prouve pas que l'authentificateur est présent : quiconque connaît le secret est accepté comme son titulaire.
Explication de la marmotte
Imagine que chaque site où tu as un compte te confie un cadenas, et que toi seul gardes la clé, rangée dans ton téléphone ou dans une petite clé à brancher. Pour te connecter, le site t'envoie une énigme toute neuve. Ton appareil la résout avec ta clé, après avoir vérifié ton empreinte ou ton code. Le site contrôle la réponse avec son cadenas, sans jamais voir la clé. Tu n'as plus de mot de passe à retenir, et il n'y a plus rien à voler sur le site. Si un faux site imite le vrai, ton appareil le remarque et refuse de répondre.
Où ce terme est utilisé
- Authentification défi-réponse, rejeu, relais et attaque hors ligne (10 occurrences)
- Déployer WebAuthn FIDO2 passwordless sur une application web (10 occurrences)
- Authentifier les personnes et les services (3 occurrences)
- Déployer FIDO2 pour comptes à privilèges (3 occurrences)
- Gouverner les facteurs d’authentification en entreprise (3 occurrences)
- Divulgation sélective : prouver qu'on est majeur sans montrer sa date de naissance (2 occurrences)
- Les passkeys, et ce qui se déplace (2 occurrences)
- Niveaux d'assurance d'authentification : ce qu'il faut pour monter d'un cran (2 occurrences)
- Assertion fédérée injectée : pourquoi une assertion valide ne suffit pas (1 occurrence)
- Attaque de l'intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLS (1 occurrence)