Serveur Authent Web WebAuthN

Depuis avril 2018, une nouvelle spec du W3 est implémentée dans firefox nightly : WebAuthN. Aujourd’hui, elle est également présente dans Chrome et Microsoft Edge.

Mais WebAuthN qu’est-ce que c’est exactement ? Cette nouvelle norme promet de pouvoir remplacer les mots de passe classiques par des intermédiaires biométriques (capteur d’empreinte, reconnaissance faciale, iris, …) ou n’importe quelle clé ou dongle USB (exemple, les clés YUBICO).

Acteurs de la norme

Tous les acteurs du web participent à cette nouvelle norme. Elle est rédigée par le W3, et est une implémentation technique dans les navigateurs d’une méthode authentification plus grande : FIDO 2. (Alibaba, Amazon, Facebook, Google, Micosoft, Mozilla, …). Cette norme, qui fait suite à la norme FIDO, est la continuité des initiatives de connexions via des clés sécurisées, mais cette fois si avec une sécurité augmentée, et des devices compatibles biométriques.

Les concepts apportés

La théorie est assez simple : votre navigateur va créer une clé privée et une clé publique. Si vous stockez la clé privée dans un emplacement sécurisé (Navigator Credentials) et que vous donnez la clé publique à tout site web sur lequel vous souhaitez vous authentifier, l’authentification devient radicalement plus sûre. Disons qu’un site Web a votre clé publique. S’ils veulent s’assurer que vous êtes qui vous prétendez être, ils peuvent vous envoyer des données aléatoires appelées un challenge. Il vous suffit de signer ce challenge avec votre clé privée et de renvoyer le résultat de cette signature sur le site Web. Le site Web peut alors vérifier votre signature avec votre clé publique. Si c’est valide, vous pouvez vous connecter.

Vos clés privées peuvent exister dans un emplacement sûr et être utilisées uniquement pour générer une réponse à usage unique à un challenge d’authentification.

Sans mot de passe, chaque clé privée peut être aussi longue et aléatoire que nécessaire pour rester sécurisée (pas limitée par la mémoire humaine). Cela augmente considérablement la sécurité des services Web individuels car il est impossible de deviner une clé privée générée aléatoirement.

Sans mot de passe, un site Web piraté ne contient qu’une liste de clés publiques parfaitement inutiles. Si quelqu’un de malveillant accède à votre clé publique, il ne peut toujours pas l’utiliser pour se connecter. Mieux encore, FIDO2 génère une paire de clés privée / publique unique pour chaque site Web. Cela signifie que si votre fournisseur de messagerie est piraté, personne ne pourra lier ce compte à votre compte bancaire en ligne par exemple.

Sans mot de passe, même si quelqu’un communique avec votre site Web par le biais d’une communication de type «challenge-response», il ne peut pas signer un autre challenge sans votre clé privée sécurisée. Les sites Web génèrent des défis de manière aléatoire et chacun est utilisé une seule fois. Si quelqu’un surveille le trafic, il ne peut non seulement pas copier votre signature, mais il ne peut même pas utiliser cette signature une fois pour se connecter.

On comprends donc rapidement les avantages énormes apportés par ce type de connexion.

Flow de connexion

Le flow technique générique de connexion est représenté ci-dessous. L’idée est donc de proposer à l’utilisateur d’utiliser une méthode authentification disponible sur son device, ou extérieure à ce dernier, comme une montre connectée par exemple.

Chiffrement

Cette nouvelle norme se base sur plusieurs techniques de chiffrement :

• Lors de sa demande de création de compte, le client envoie ses informations de connexion (username, nom, prénom, …), et reçoit en échange du serveur un challenge à résoudre (random bytes + d’autres informations nécessaires comme le type d’attestation) :

{
    challenge: randomBase64URLBuffer(32),

    rp: {
        name: "Oui.sncf"
    },

    user: {
        id: id,
        name: username,
        displayName: displayName
    },

    attestation: 'direct',

    pubKeyCredParams: [
        {
            type: "public-key", alg: -7 // "ES256" IANA COSE Algorithms registry
        }
    ]
}

• Ensuite, le client va créer des clés privées et publiques pour cet enregistrement. C’est à ce moment là que les périphériques de connexion type clé ou biométriques sont appelés pour générer ces clés. Le navigateur renvoie alors au server sa clé publique + sa réponse à la demande de challenge (challenge signé avec la clé privée du navigateur).
• Le serveur vérifie que le challenge résolut par le client est bien le même que celui de la réponse (soit par un système de session, soit via un token type JWT). Une vérification de l’origine de la réponse du client est également conseillée. Le serveur vérifie également que le challenge est signé par la clé publique indiquée par le client.

• Le système de login est ensuite similaire, avec un challenge envoyé par le serveur quand le client demande à se connecter avec son username. En plus du challenge, le serveur fournit les authenticators connus du client :

{
      type: 'public-key',
      id: authr.credID,
      transports: ['usb', 'nfc', 'ble']
}

• Le navigateur signe le challenge avec sa clé privée et le renvoie
• Le serveur vérifie que le challenge a été signé avec le périphérique connu de l’utilisateur, déclaré à l’enregistrement du compte.

Architecture POC

Pour le moment, il n’existe pas de serveurs d’exemple qui implémente cette nouvelle norme combinée à des techniques d’authentifications plus standard comme les Json Web Tokens. Nous avon donc créé un serveur qui implémente ces 2 concepts, avec la stack suivante :

• Nest.js : Framework de Serveur Node.js basé sur Express, utilisant le langage Typescript
• Passport : Un outil Node.js qui facilite l’authentification avec des JWT
• Mongo.DB : pour le stockage des comptes utilisateur

Le flux est donc celui décrit ci-dessus, mais avec l’utilisation des JWT pour le stockage des challenges et la connexion utilisateur une fois son challenge vérifié.

Vous trouverez ici le code open sourced du projet : https://github.com/voyages-sncf-technologies/webauthn-server

Features à venir

Pour le moment, bien qu’implémentée dans plusieurs navigateurs, WebauthN n’est compatible qu’avec la clé de développement Yubico Fido 2. Des mises à jours permettrons d’utiliser les périphériques biométriques de nos devices.

Autre langages

Il existe quelques initiatives de serveur dans d’autres langages :

• Server en go https://github.com/duo-labs/webauthn

Documentation utile sur le sujet

• Specification Google sur le sujet :

Enabling Strong Authentication with WebAuthn | Web | Google Developers

• Spécification Mozilla : https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API