Ces choses appelées clés d'accès font le tour ces jours-ci. Ils étaient une attraction principale à W3C TPAC 2022, a obtenu le soutien de Safari 16, trouvent leur place dans macOS et iOS, et devraient être l'avenir des gestionnaires de mots de passe comme 1Password. Ils sont déjà supporté dans Android, et trouveront bientôt leur place dans Chrome OS et Windows dans les prochaines versions.

Les améliorations de sécurité de Geeky OS ne font pas vraiment les gros titres dans la communauté frontale, mais il va de soi que les clés de passe vont être une «chose». Et compte tenu de la façon dont les mots de passe et les applications de mot de passe affectent l'expérience utilisateur de choses comme l'authentification et le traitement des formulaires, nous voudrions peut-être au moins les comprendre, afin que nous sachions ce qui s'en vient.

C'est le but de cet article. J'étudie et j'expérimente les mots de passe - et l'API WebAuthn sur laquelle ils sont construits - depuis un certain temps maintenant. Permettez-moi de partager ce que j'ai appris.

Table des matières

Terminologie

Voici la section obligatoire de la terminologie que vous voudrez connaître au fur et à mesure que nous creuserons. Comme la plupart des technologies, les mots de passe sont forgés avec un verbiage ésotérique et des acronymes qui sont souvent des obstacles à la compréhension. Je vais essayer de démystifier plusieurs pour vous ici.

• Partie de confiance: le serveur auprès duquel vous vous authentifierez. Nous utiliserons "serveur" pour impliquer la partie utilisatrice dans cet article.
• Client: dans notre cas, le navigateur Web ou le système d'exploitation.
• Authentificateur : Dispositifs logiciels et/ou matériels qui permettent la génération et le stockage de paires de clés publiques.
• FIDO: Un organisme de normalisation ouvert qui crée également des spécifications autour des informations d'identification FIDO.
• Webauthn: Le protocole sous-jacent pour les mots de passe, également connu sous le nom de FIDO2 des informations d'identification ou des informations d'identification FIDO pour un seul appareil.
• Clés d'accès: WebAuthn, mais avec synchronisation dans le cloud (également appelées informations d'identification FIDO multi-appareils, informations d'identification détectables ou informations d'identification résidentes).
• Cryptographie à clé publique : Une paire de clés générée qui comprend une clé privée et une clé publique. Selon l'algorithme, il doit être utilisé soit pour la signature et la vérification, soit pour le chiffrement et le déchiffrement. Ceci est également connu sous le nom de cryptographie asymétrique.
• RSA: Un acronyme des noms des créateurs, Rivest Shamir et Adel. RSA est une famille de cryptographie à clé publique plus ancienne, mais toujours utile, basée sur la factorisation des nombres premiers.
• Cryptographie à courbe elliptique (ECC): Une nouvelle famille de cryptographie basé sur des courbes elliptiques.
• ES256: Une clé publique à courbe elliptique qui utilise un algorithme de signature ECDSA (PDF) avec SHA256 pour le hachage.
• RS256: Comme ES256, mais il utilise RSA avec RSASSA-PKCS1-v1.5 et SHA256.

Qu'est-ce qu'un passe-partout ?

Avant de pouvoir parler spécifiquement des clés d'accès, nous devons parler d'un autre protocole appelé Webauthn (également connu sous le nom de FIDO2). Les clés de passe sont une spécification construite au-dessus de WebAuthn. WebAuthn permet à la cryptographie à clé publique de remplacer les mots de passe. Nous utilisons une sorte de dispositif de sécurité, comme une clé matérielle ou Trusted Platform Module (TPM), pour créer des clés privées et publiques.

La clé publique est accessible à tous. La clé privée, cependant, ne peut pas être supprimée de l'appareil qui l'a générée. C'était l'un des problèmes avec WebAuthn; si vous perdez l'appareil, vous perdez l'accès.

Passkeys résout ce problème en fournissant une synchronisation cloud de vos informations d'identification. En d'autres termes, ce que vous générez sur votre ordinateur peut désormais également être utilisé sur votre téléphone (bien que, ce qui prête à confusion, il existe également des informations d'identification sur un seul appareil).

Actuellement, au moment de la rédaction, seuls iOS, macOS et Android offrent une prise en charge complète des clés de sécurité synchronisées dans le cloud, et même dans ce cas, ils sont limités par le navigateur utilisé. Google et Apple proposent une interface de synchronisation via leur Gestionnaire de mots de passe Google ainsi que  Porte-clés Apple iCloud services, respectivement.

Comment les clés d'accès remplacent-elles les mots de passe ?

Dans la cryptographie à clé publique, vous pouvez effectuer ce que l'on appelle signature. La signature prend une donnée, puis la fait passer par un algorithme de signature avec la clé privée, où elle peut ensuite être vérifiée avec la clé publique.

N'importe qui peut générer une paire de clés publiques, et cela n'est attribuable à personne puisque n'importe qui aurait pu la générer en premier lieu. Ce qui le rend utile, c'est que seules les données signées avec la clé privée peuvent être vérifiées avec la clé publique. C'est la partie qui remplace un mot de passe - un serveur stocke la clé publique, et nous nous connectons en vérifiant que nous avons l'autre moitié (par exemple, la clé privée), en signant un défi aléatoire.

Comme avantage supplémentaire, puisque nous stockons les clés publiques de l'utilisateur dans une base de données, il n'y a plus de souci avec les violations de mot de passe affectant des millions d'utilisateurs. Cela réduit le phishing, les violations et une multitude d'autres problèmes de sécurité auxquels notre monde dépendant des mots de passe est actuellement confronté. Si une base de données est piratée, tout cela est stocké dans les clés publiques de l'utilisateur, ce qui la rend pratiquement inutile pour un attaquant.

Finis les emails oubliés et leurs mots de passe associés non plus ! Le navigateur se souviendra des informations d'identification que vous avez utilisées pour quel site Web - tout ce que vous avez à faire est de faire quelques clics et vous êtes connecté. Vous pouvez fournir un moyen de vérification secondaire pour utiliser le mot de passe, comme la biométrie ou une épingle , mais ceux-ci sont toujours beaucoup plus rapides que les mots de passe d'antan.

En savoir plus sur la cryptographie

La cryptographie à clé publique implique d'avoir une clé privée et une clé publique (appelée paire de clés). Les clés sont générées ensemble et ont des utilisations distinctes. Par exemple, la clé privée est destinée à rester secrète et la clé publique est destinée à la personne avec qui vous souhaitez échanger des messages.

Lorsqu'il s'agit de chiffrer et de déchiffrer un message, la clé publique du destinataire est utilisée pour chiffrer un message afin que seule la clé privée du destinataire puisse déchiffrer le message. Dans le langage de la sécurité, cela s'appelle « assurer la confidentialité ». Cependant, cela ne fournit pas la preuve que l'expéditeur est bien celui qu'il prétend être, car n'importe qui peut potentiellement utiliser une clé publique pour envoyer à quelqu'un un message chiffré.

Il y a des cas où nous devons vérifier qu'un message provient bien de son expéditeur. Dans ces cas, nous utilisons la signature et la vérification de signature pour nous assurer que l'expéditeur est bien celui qu'il prétend être (également appelé authenticité). En clé publique (également appelée asymétrique) la cryptographie, cela se fait généralement en signant le hash d'un message, afin que seule la clé publique puisse correctement le vérifier. Le hachage et la clé privée de l'expéditeur produisent une signature après l'avoir exécuté via un algorithme, puis n'importe qui peut vérifier que le message provient de l'expéditeur avec la clé publique de l'expéditeur.

Comment accédons-nous aux clés d'accès ?

Pour accéder aux clés de sécurité, nous devons d'abord les générer et les stocker quelque part. Certaines de ces fonctionnalités peuvent être fournies avec un authentificateur. Un authentificateur est tout dispositif matériel ou logiciel qui offre la possibilité de générer des clés cryptographiques. Pensez à ces mots de passe à usage unique que vous obtenez de Authentificateur Google, 1Passwordou LastPass, entre autres.

Par exemple, un authentificateur logiciel peut utiliser le module de plateforme sécurisée (TPM) ou l'enclave sécurisée d'un appareil pour créer des informations d'identification. Les informations d'identification peuvent ensuite être stockées à distance et synchronisées sur tous les appareils, par exemple les clés de passe. Un authentificateur matériel serait quelque chose comme un YubiKey, qui peut générer et stocker des clés sur l'appareil lui-même.

Pour accéder à l'authentificateur, le navigateur doit avoir accès au matériel, et pour cela, nous avons besoin d'une interface. L'interface que nous utilisons ici est le protocole Client to Authenticator (CTAP). Il permet d'accéder à différents authentificateurs via différents mécanismes. Par exemple, nous pouvons accéder à un authentificateur via NFC, USB et Bluetooth en utilisant CTAP.

L'une des façons les plus intéressantes d'utiliser les clés de sécurité consiste à connecter votre téléphone via Bluetooth à un autre appareil qui pourrait ne pas prendre en charge les clés de sécurité. Lorsque les appareils sont couplés via Bluetooth, je peux me connecter au navigateur de mon ordinateur en utilisant mon téléphone comme intermédiaire !

La différence entre les clés de sécurité et WebAuthn

Les clés d'accès et les clés WebAuthn diffèrent de plusieurs manières. Tout d'abord, les clés d'accès sont considérées comme des informations d'identification multi-appareils et peuvent être synchronisées sur tous les appareils. En revanche, les clés WebAuthn sont des informations d'identification sur un seul appareil - une façon élégante de dire que vous êtes lié à un appareil pour vérification.

Deuxièmement, pour s'authentifier auprès d'un serveur, les clés WebAuthn doivent fournir le descripteur d'utilisateur pour la connexion, après quoi un allowCredentials La liste est renvoyée au client par le serveur, qui indique les informations d'identification pouvant être utilisées pour se connecter. Les clés de passe ignorent cette étape et utilisent le nom de domaine du serveur pour indiquer quelles clés sont déjà liées à ce site. Vous pouvez sélectionner le mot de passe associé à ce serveur, car il est déjà connu par votre système.

Sinon, les clés sont cryptographiquement identiques ; ils ne diffèrent que par la manière dont ils sont stockés et les informations qu'ils utilisent pour démarrer le processus de connexion.

Le processus… en quelques mots

Le processus de génération d'un WebAuthn ou d'un mot de passe est très similaire : obtenez un défi du serveur, puis utilisez le navigator.credentials.create API Web pour générer une paire de clés publiques. Ensuite, renvoyez le défi et la clé publique au serveur pour qu'ils soient stockés.

A réception de la clé publique et du challenge, le serveur valide le challenge et la session à partir de laquelle il a été créé. Si cela est vérifié, la clé publique est stockée, ainsi que toute autre information pertinente comme l'identifiant de l'utilisateur ou les données d'attestation, dans la base de données.

L'utilisateur a une étape de plus - récupérer un autre défi du serveur et utiliser le navigator.credentials.get API pour signer le défi. Nous renvoyons le défi signé au serveur, et le serveur vérifie le défi, puis nous connecte si la signature passe.

Il y a, bien sûr, un peu plus à chaque étape. Mais c'est généralement ainsi que nous nous connectons à un site Web à l'aide de WebAuthn ou de mots de passe.

La viande et les pommes de terre

Les clés de sécurité sont utilisées en deux phases distinctes : la attestation ainsi que  affirmation étapes.

La phase d'attestation peut également être considérée comme la phase d'enregistrement. Vous vous inscrirez avec un e-mail et un mot de passe pour un nouveau site Web, cependant, dans ce cas, nous utiliserons notre mot de passe.

La phase d'affirmation est similaire à la façon dont vous vous connectez à un site Web après votre inscription.

Attestation

La navigator.credentials.create L'API est au centre de notre phase d'attestation. Nous sommes enregistrés en tant que nouvel utilisateur dans le système et devons générer une nouvelle paire de clés publiques. Cependant, nous devons spécifier le type de paire de clés que nous voulons générer. Cela signifie que nous devons fournir des options pour navigator.credentials.create.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = { challenge: safeEncode(challenge), rp: { id: window.location.host, name: document.title, }, user: { id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random? name: 'Your username', displayName: 'Display name in browser', }, pubKeyCredParams: [ { type: 'public-key', alg: -7, // ES256 }, { type: 'public-key', alg: -256, // RS256 }, ], authenticatorSelection: { userVerification: 'preferred', // Do you want to use biometrics or a pin? residentKey: 'required', // Create a resident key e.g. passkey }, attestation: 'indirect', // indirect, direct, or none timeout: 60_000,
};

const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({ publicKey
});
const { id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration

Nous aurons PublicKeyCredential qui contient un AuthenticatorAttestationResponse qui revient après la création. L'identifiant a l'ID de la paire de clés générée.

La réponse fournit quelques informations utiles. Tout d'abord, nous avons notre clé publique dans cette réponse, et nous devons l'envoyer au serveur pour qu'elle soit stockée. Deuxièmement, nous récupérons également le clientDataJSON propriété que nous pouvons décoder, et à partir de là, récupérer la type, challengeet origin du passe-partout.

Pour l'attestation, nous voulons valider le type, challengeet origin sur le serveur, ainsi que stocker la clé publique avec son identifiant, par exemple kid. Nous pouvons également éventuellement stocker le attestationObject si nous le souhaitons. Une autre propriété utile à stocker est la COSE algorithme, qui est défini ci-dessus dans notre  PublicKeyCredentialCreationOptions avec alg: -7 or alg: -256, afin de vérifier facilement tous les défis signés dans la phase d'assertion.

Affirmation

La navigator.credentials.get L'API sera au centre de la phase d'assertion. Conceptuellement, il s'agirait de l'endroit où l'utilisateur se connecte à l'application Web après s'être inscrit.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = { challenge: new TextEncoder().encode(challenge), rpId: window.location.host, timeout: 60_000,
};

const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({ publicKey, mediation: 'optional',
});
const { id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification

Nous aurons à nouveau un PublicKeyCredential peut comprendre un atténuateur. AuthenticatorAssertionResponse ce temps. Les informations d'identification incluent à nouveau l'identifiant de la clé.

On obtient également le type, challengeet origin du clientDataJSON de nouveau. Le signature est maintenant inclus dans la réponse, ainsi que le authenticatorData. Nous aurons besoin de ceux-ci et du clientDataJSON pour vérifier qu'il a été signé avec la clé privée.

La authenticatorData inclut certaines propriétés qui méritent d'être suivies Le premier est le hachage SHA256 de l'origine que vous utilisez, situé dans les 32 premiers octets, ce qui est utile pour vérifier que la demande provient du même serveur d'origine. La deuxième est la signCount, qui est de l'octet 33 à 37. Ceci est généré à partir de l'authentificateur et doit être comparé à sa valeur précédente pour s'assurer que rien de louche ne se passe avec la clé. La valeur doit toujours être égale à 0 lorsqu'il s'agit d'un passe-partout multi-appareils et doit être aléatoirement plus grande que le signCount précédent lorsqu'il s'agit d'un passe-partout pour un seul appareil.

Une fois que vous avez confirmé votre identifiant, vous devriez être connecté — félicitations! Passkeys est un très bon protocole, mais il comporte quelques mises en garde.

Quelques inconvénients

Il y a beaucoup d'avantages à Passkeys, cependant, il y a quelques problèmes avec cela au moment d'écrire ces lignes. D'une part, les clés de passe sont encore un peu précoces en termes de support, avec uniquement des informations d'identification sur un seul appareil autorisées sur Windows et très peu de support pour les systèmes Linux. Clés d'accès.dev fournit une belle table qui ressemble un peu à la Caniuse de ce protocole.

De plus, les plates-formes de clés d'authentification de Google et d'Apple ne communiquent pas entre elles. Si vous souhaitez obtenir vos informations d'identification de votre téléphone Android sur votre iPhone… eh bien, vous n'avez pas de chance pour l'instant. Cela ne veut pas dire qu'il n'y a pas d'interopérabilité ! Vous pouvez vous connecter à votre ordinateur en utilisant votre téléphone comme authentificateur. Mais ce serait beaucoup plus propre de l'intégrer simplement au système d'exploitation et de le synchroniser sans qu'il soit verrouillé au niveau du fournisseur.

Où vont les choses ?

À quoi ressemble le protocole des clés d'accès du futur ? Ça a l'air plutôt bien ! Une fois qu'il sera pris en charge par davantage de systèmes d'exploitation, il devrait y avoir une utilisation croissante et vous commencerez à le voir de plus en plus utilisé dans la nature. Quelques gestionnaires de mots de passe vont même les soutenir de première main.

Les clés de passe ne sont en aucun cas uniquement prises en charge sur le Web. Android ainsi que  iOS prendront tous deux en charge les clés de sécurité natives en tant que citoyens de première classe. Nous en sommes encore aux premiers jours de tout cela, mais attendez-vous à en voir de plus en plus parler.

Après tout, nous éliminons le besoin de mots de passe et, ce faisant, rendons le monde plus sûr pour lui !

Ressources

Voici quelques ressources supplémentaires si vous souhaitez en savoir plus sur les Passkeys. Il y a aussi un référentiel et une démo que j'ai mis en place pour cet article.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://css-tricks.com/passkeys-what-the-heck-and-why/