La cérémonie d’enregistrement WebAuthn, pas à pas

L’enregistrement est le moment où un utilisateur vous remet une clé publique. Tout ce sur quoi vous vous appuierez ensuite dépend de la bonne exécution de ces six étapes.

Les six étapes

  1. Votre serveur engendre des options de création : un défi aléatoire, l’identité de la partie utilisatrice, l’identifiant d’utilisateur, et votre politique.
  2. Le navigateur les transmet à l’authentificateur.
  3. L’authentificateur crée une paire de clés, garde la moitié privée, et signe un objet d’attestation.
  4. Le navigateur renvoie cet objet à votre serveur.
  5. Votre serveur le vérifie : le défi, l’origine, l’empreinte de la partie utilisatrice, les drapeaux, la signature.
  6. Vous rangez l’identifiant d’authentifiant, la clé publique, et le compteur de signature.

Le défi doit être le vôtre, une seule fois

Engendrez-le côté serveur, au moins seize octets aléatoires, rangez-le avec la session, et supprimez-le après un usage. Un défi que l’on peut rejouer n’est pas un défi.

L’erreur à éviter : l’engendrer en JavaScript. Toute la cérémonie repose sur le fait que le serveur a choisi une valeur que le client ne pouvait pas prédire.

L’identifiant d’utilisateur n’est pas le nom d’utilisateur

L’identifiant d’utilisateur désigne le compte auprès de l’authentificateur. Il finit rangé sur l’appareil, parfois affiché dans une boîte de dialogue du système, et ce n’est pas la place d’une adresse électronique ni de quoi que ce soit que vous préféreriez ne pas voir là.

Employez un identifiant opaque et stable, de soixante-quatre octets au plus. Une valeur aléatoire reliée à votre compte dans votre propre base est la bonne réponse.

Le contrôle d’origine est la propriété anti-hameçonnage

Le navigateur consigne l’origine sur laquelle il se trouvait et l’authentificateur signe dessus. Votre serveur vérifie qu’elle correspond. Ce seul contrôle est ce qui rend WebAuthn résistant à l’hameçonnage, et c’est pourquoi un domaine sosie ne peut pas obtenir de réponse exploitable.

À ce propos : la version 5.3.4 du framework a corrigé un cas où les réponses multi-origines étaient acceptées quand aucun validateur d’origine supérieure n’était configuré. Le défaut sûr est de refuser, et c’est désormais ce qu’il fait.

Dans Symfony

composer require web-auth/webauthn-framework

Le bundle expose les routes et la cérémonie, et un composant Stimulus s’occupe du côté navigateur. La documentation couvre la configuration ; l’article suivant couvre ce qui se passe quand l’utilisateur revient.