On admet généralement que les mots de passe auront disparu de la circulation avant 2030. Mais pour les remplacer, les solutions ne sont pas encore très nombreuses et surtout les standards qui pourraient en constituer le socle ne sont pas disponibles ou sont peu connus. Dans ce contexte, l’initiative WebAuthn que l’on doit à l’alliance FIDO (Fast Identity Online), doit être suivie de près, dans la mesure où depuis 2013 elle regroupe les ténors du domaine, parmi lesquels Microsoft, Google, Mozilla, Intel, PayPal, Lenovo, etc.

La norme WebAuthn en est aujourd’hui à la phase finale de reconnaissance, contrairement à la précédente WAF du même FIDO, qui n’avait guère dépassé le périmètre restreint de Google. Cette fois tout le monde est d’accord, y compris Apple qui n’avait pas été très positif sur ce sujet, mais « semble » s’est rallié à l’offre commune.

Sur le principe, WebAuthn est une API JavaScript dont l’objectif est de remplacer dans le navigateur le couple mot de passe/login, par une authentification forte effectuée sur un équipement connecté au poste de travail ou mobile qui a besoin d’une authentification. Le mot de passe étant remplacé par une bi-clé : publique et privée.

Tout se fait par le biais d’une connexion sécurisée HTTPS et le processus se déroule en deux phases : authentification des « clients » auprès du fournisseur de service compatible WebAuthn et reconnaissance ultérieure.

Il faut pour cela utiliser un navigateur compatible : Chrome, Edge, Firefox…et avoir implémenté le mécanisme dans la procédure d’authentification, ce qui implique un effort de développement de la part des usagers, pas forcément très simple à comprendre et à effectuer.

Même si FIDO 1 avec WAF n’a pas été un succès, il est probable que la nouvelle norme va tout balayer et que nous sommes à l’aube d’une ère nouvelle, sans mot de passe. Tout ne se fera pas en un jour, car les (mauvaises) habitudes seront difficiles à oublier, mais il est impératif que les entreprises se préparent à l’ordre nouveau. Car il n’y a pas d’alternative. Les mos de passe peuvent et doivent disparaître. Et si ce n’est avec FISO2 ce sera avec autre chose…

FIDO 1 est mort, longue vie à FIDO 2

L’alliance FIDO était déjà à l’origine de deux méthodes d’authentification pour les mobiles, UAF (Universal Authentication Framework) et U2F (Universal Second Factor).

Avec UAF il s’agissait « seulement » de remplacer le mot de passe par un mécanisme d’authentification forte sur le mobile, celui-ci étant déclaré par le propriétaire du mobile auprès d’un service en ligne : une séquence sonore à prononcer dans le micro, la reconnaissance du visage via la caméra, voire un balayage de doigt à l’écran.

U2F allait un peu plus loin et ajoutait un deuxième facteur d’authentification, à celui qui existait déjà (mot de passe/identifiant), en respectant un processus à deux phases : le choix d’un système d’authentification fort implémenté localement dans le mobile et la génération d’un couple de bi-clés (publique et privée), la clé publique étant stockée chez le fournisseur de service et la clé privée restant enfouie dans le mobile de l’usager. Il y avait donc autant de couples de clés que d’associations entre utilisateurs, fournisseurs de services, système d’authentification forte et compte utilisateur chez le fournisseur de services. On verra qu’il y a plus qu’une similitude entre U2F et FIDO2 de WebAuthn.

La grande différence était donc que le service en ligne n’avait pas besoin de conserver les mots de passe de ses clients, ce qui constituait la principale de ses faiblesses, à l’origine de nombreuses tentatives de phishing.

C’est ce système qui est à la base de FIDO2, alias WebAuthn, celui-ci étant surtout une mise à jour de l’API, adoptée dorénavant par tout le monde, l’API étant chargée de mettre en œuvre le protocole CTAP (Client-To-Authenticator Protocol) d’authentification forte, à l’intérieur du navigateur, autrement dit le lien entre le dispositif de sécurité (lecteur d’empreintes…) et le navigateur.

Il faut bien comprendre que l’utilisateur va devoir faire un effort de développement dans son application serveur, s’il veut se rendre compatible avec le mécanisme sur le poste client. D’où la nécessité qu’il comprenne bien la mise en œuvre de l’API JavaScript qui en constitue le cœur.

Le fonctionnement de WebAuthn

Le mécanisme WebAuthn met en scène trois acteurs : le navigateur Internet du client, un fournisseur de services en ligne (e-commerce, portails, banques, etc), que l’on appelle parfois le « relying party » ou « tiers de confiance » et un équipement chargé de la partie authentification forte, le dispositif de sécurité, tel qu’un lecteur d’empreintes digitales, un outil de reconnaissance de la géométrie du visage ou tout autre disposition, une clé USB, à condition que l’équipement soit reconnu par le nouveau standard (il y en a actuellement plus de 400).

Le transport physique entre la clé de sécurité et le « browser » n’est pas décrit dans le standard et peut être mis en œuvre de différentes manières : une connexion physique sur port USB de la machine cliente, une connexion sans fil NFC entre un smartphone porteur du lecteur d’empreintes digitales, par exemple, une connexion Wi-Fi, etc.

Le process WebAuthn comporte deux grandes phases : la déclaration initiale par laquelle le client browser va indiquer quel est le système d’authentification forte qu’il veut utiliser et une phase de reconnaissance, qui interviendra à chaque fois qu’il voudra ensuite se connecter. Etant entendu que FIDO2 est surtout destiné à des sites que l’on veut sécuriser et auxquels on se connecte régulièrement.

Les deux phases sont mises en œuvre grâce à l’API JavaScript.

La déclaration initiale est lancée automatiquement dès lors que l’usager se connecte, l’application de service lui demandant s’il veut exploiter un système déjà déclaré où s’il veut en « fabriquer » un autre.

Si c’est la première fois qu’il se connecte, il optera pour la seconde possibilité. Dès lors, l’application serveur lui proposera un challenge, en fait un message dans lequel vont se trouver diverses informations, dont l’IP du demandeur, mais aussi une valeur aléatoire sur 32 octets, qui servira au client pour construire sa réponse.

C’est là que se trouve un point clé de la technologie WebAuthn. Car pour répondre au challenge serveur, le dispositif de sécurité va fabriquer une bi-clé, constituée par conséquent d’une clé publique, qu’il va inclure dans sa réponse et d’une clé privée, qu’il va stocker localement et ne sera connue que de lui seul. C’est avec cette clé privée qu’il va signer sa réponse au challenge.

De cette manière le service va récupérer la clé publique qu’il conservera pour les connexions futures et contrôlera que « celui qui répond » est bien celui qu’il prétend être, grâce au déchiffrement qu’il effectuera avec la clé publique. Qui lui permettra entre-autre de s’assurer que la valeur aléatoire se trouve bien dans la réponse au challenge.

Ce mécanisme paraît très sûr, sans doute pas inviolable, mais difficile à circonvenir grâce à la conjonction entre le challenge et sa séquence aléatoire et le jeu de clés générées par le dispositif physique de sécurité. Car si un attaquant veut pénétrer une session, il lui faudra posséder à la fois la clé privée générée et le dispositif de sécurité. Ce qui semble hautement improbable. Si quelqu’un s’empare du dispositif physique, il ne disposera pas de la clé privée, qui aura été générée à la demande d’enregistrement.

A partir de là, le processus sera toujours le même. Il suffira au client de faire contrôler son empreinte digitale, s’il a choisi ce dispositif, le browser émettant un message d’authentification signé avec sa clé privée et comportant la fameuse chaîne aléatoire de 32 bytes, que le serveur vérifiera en s’assurant que les demandes de connexion sont signées par celui qui a le droit de le faire, sans avoir besoin pour cela d’un échange de mots de passe.

Le fonctionnement de l’API

En termes de codage, les développeurs des entreprises vont devoir fabriquer ou modifier leurs applications de services en lignes, pour leur permettre d’implémenter FIDO2.

Ils se serviront de l’API WebAuthn qui étend les deux méthodes JavaScript, de manière à ce qu’elles supportent le paramètre publicKey :

• navigator.credentials.create(), dont l’objet est de créer les comptes nouveaux associés au dispositif d’authentification forte ou de modifier les comptes existants pour qu’ils soient reconnus comme tels.
• navigator.credentials.get(), qui permet de reconnaître un compte déclaré, via le mécanisme fort adopté.

Pour s’assurer que le browser qu’ils utiliseront est compatible avec WebAuthn, ils devront s’assurer que l’interface window.PublicKeyCredential est définie.

Le standard définit par ailleurs de nouvelles interfaces AuthenticatorAttestationResponse et AuthenticatorAssertionResponse, en complément de dictionnaires et de datatypes nouveaux.

Même s’il faut être prudent et ne pas prendre pour argent comptant ce que nous disent les éditeurs, Google est conforme « a priori » depuis Chrome 67, Mozilla depuis Firefox 60 et Microsoft depuis le Build Redstone 5 de Edge sous Windows 10, présenté au début 2018.