Les passkeys, pour l’instant faiblement présentes dans les plateformes et applications, sont amenées à se répandre un peu partout dans les années qui viennent. Pour en comprendre l’intérêt, nous revenons sur leur fonctionnement – sur la base des informations actuellement disponibles –, avec des questions/réponses simples, avant de nous pencher sur la pratique.
Les passkeys ont pour mission de remplacer avantageusement les mots de passe. Pourquoi ? Parce que ces derniers accumulent les problèmes depuis longtemps, et que même les gestionnaires dédiés ne peuvent plus contrebalancer certains traits inhérents aux mots de passe.
En premier lieu, ils ne sont pas pratiques. Il faut en créer un différent pour chaque service, pour ne pas risquer une hécatombe de piratages. En effet, réutiliser le même mot de passe expose à des compromissions en série, puisqu’il suffit que des pirates devinent le mot de passe d’un seul service pour s’attaquer à tous les autres. Et non seulement il en faut un différent, mais chacun doit être assez long (au moins 12 caractères) et utiliser les quatre types : majuscules, minuscules, chiffres et caractères spéciaux.
Résultat, on se retrouve vite avec une quantité importante de chaines de caractères difficiles à mémoriser. C’est là que les gestionnaires de mots de passe entrent en piste, en permettant la génération de chaines aléatoires de caractères. Puisqu’ils enregistrent ces informations et les resservent quand nécessaire, on gagne en temps et en sécurité. Rien n’empêche en effet de créer des mots de passe aléatoires de 40 caractères.
Les gestionnaires ne peuvent cependant pas grand-chose contre d’autres aspects problématiques des mots de passe, dont le principal : ils peuvent être volés. Qu’il s’agisse d’une fuite de données chez un prestataire de service, d’un mot de passe trop faible ou du résultat d’une campagne d'hameçonnage, le résultat sera le même : des identifiants dans la nature.
Mais le second facteur ne permet-il pas de juguler ce problème ? Oui, du moins en partie. Se servir du téléphone est une bonne idée au départ, et nous allons voir qu’il va jouer un rôle prépondérant pour les passkeys. Avec les applications actuelles néanmoins, il arrive encore que le code soit envoyé par SMS. Même quand il est généré par une application de type Authenticator (Google, LastPass, Microsoft, etc.), il peut quand même être intercepté. C’est bien sûr plus délicat à réaliser, mais loin d’être impossible.
Les passkeys se proposent de résoudre tous ces problèmes. Elles se veulent plus simples d’utilisation et surtout plus sécurisées, en empêchant l’information identifiante d’être volée. Des tentatives ont déjà été faites par le passé pour se débarrasser des mots de passe, mais c’est la première fois qu’une vaste alliance travaille sur le sujet. Bien que l’on en parle maintenant, les passkeys sont en préparation depuis des années et impliquent notamment Apple, Google et Microsoft, l’ensemble étant chapeauté par la FIDO Alliance.
Notez pour la suite de l’article que nous gardons l’appellation anglaise « passkeys », car sa traduction française varie selon qui en parle. Apple parle par exemple de « clés d’identification », Boursorama de « clés de sécurité », d’autres encore de « codes d’accès », etc. Une cacophonie qui risque de laisser de nombreuses personnes perplexes, et peut entrainer des confusions avec des clés de sécurité comme les YubiKey et autres Titan.
Passkeys : c’est quoi ?
Une passkey est un élément d’identification, une clé permettant de prouver à un service que la personne est bien qui elle prétend être. Associée à un identifiant (pseudo, adresse email…), elle est attachée à un appareil protégé par une défense que seul l’utilisateur – en théorie – peut déverrouiller. La passkey est liée à un mécanisme complémentaire, qu’il s’agisse de biométrie (empreinte, visage), d’un code PIN ou d’un schéma (très courant sur Android).
Plus en détail, une passkey est en fait composée de deux clés, l’une publique et enregistrée par le site web ou l’application, l’autre privée et stockée sur l’appareil où elle a été créée, dans une zone sécurisée. Elle sera synchronisée avec les autres appareils liés par le même compte au sein d’un écosystème (iCloud chez Apple, Google, etc.). Cette synchronisation est chiffrée de bout en bout. Nous reparlerons de cet aspect un peu plus tard.
La création de la passkey se fait sur la base de l’API Web Authentication. Chaque clé est unique, complexe et spécifique au service qu’elle vise. Ces identifiants ne sont en fait guère différents de ceux créés par les autres services d’authentification compatibles FIDO, comme les applications ou mêmes clés de type Yubico ou Feitian. De la même manière, les identifiants générés sont invisibles et liés à la biométrie, quand celle-ci est disponible. Des mécanismes comme Touch ID et Face ID chez Apple, ou Windows Hello chez Microsoft sont déjà compatibles.
La passkey doit donc faire le lien entre un appareil que la personne possède – smartphone, tablette, ordinateur… – et qui elle est, au moyen de la biométrie, même si cette dernière peut être remplacée par un code PIN. Mais même ainsi, on reste dans l’idée d’une jonction entre un matériel et une information que seule la personne utilisatrice possède. Contrairement à l’authentification à deux facteurs toutefois, cette sécurité ne vient pas compléter le mot de passe : elle le remplace.
En quoi les passkeys sont-elles plus sécurisées que les mots de passe ?
Plusieurs mécanismes assurent un niveau de sécurité largement supérieur aux passkeys. Comme dit, leur stockage se fait en zone sécurisée. Plus précisément, cette zone dispose d’une composante matérielle sur de nombreux appareils.
Sur les iPhone et iPad par exemple, elles sont stockées dans le Trousseau, lui-même chiffré par deux clés AES-256-CGM, l’une pour les métadonnées, l’autre pour les valeurs. Cette seconde clé est intégralement protégée par la Secure Enclave, zone matériellement sécurisée qui s’occupe également de tout ce qui touche à la biométrie. Sur les smartphones Android, on retrouve des mécanismes très similaires.
La passkey n’est jamais directement envoyée à un site ou une application, à la place un jeton est émis.
Ces jetons bénéficient d’une protection supplémentaire, déjà présente dans les mécanismes actuels d’authentification compatibles FIDO : le CTAP, ou Client to Authenticator Protocol, aussi appelé flux Cross-Device Authentication. Ce protocole peut utiliser divers moyens – USB, NFC, Bluetooth Low Energy – pour vérifier que l’appareil authentifiant est proche physiquement de l’appareil sur lequel on tente de s’identifier. Ceci pour empêcher que l’élément cryptographique, s’il parvenait à être récupéré, ne puisse pas être utilisé ailleurs.
Ce dernier point est d’ailleurs un élément limitant pour l’utilisation : l’appareil sur lequel on souhaite se connecter doit avoir le Bluetooth pour que l’authentification par le téléphone puisse se faire. Pour l’instant, la solution du smartphone comme point de contrôle central a été retenue, mais les passkeys n’ont techniquement pas ce genre de limitation.
Des passkeys plus pratiques…
La création d’une passkey ne réclame presque aucune interaction, en tout cas aucune réflexion particulière, pas plus que sa conservation. L’accès à l’information est simplement conditionné au déverrouillage de l’appareil.
Contrairement aux mots de passe, il n’est pas non plus besoin de se reconnecter sur chaque appareil souhaitant accéder au service ou à l’application. Si cet appareil est relié au même compte que l’appareil où la clé a été créée, cette dernière y est synchronisée et utilisée directement. Dans le cas d’un site par exemple, ce dernier traite avec le navigateur pour accéder aux clés cryptographiques WebAuthn nécessaires, sans nécessiter d’intermédiaire ni interaction.
C’est l’aspect pratique le plus prégnant : les clés cryptographiques sont « découvrables », signifiant que tous les appareils liés par un compte peuvent se les échanger. Dans un premier temps toutefois, il est probable que les éditeurs (sites, applications, services…) passent par des codes QR à scanner depuis une application mobile pour établir et valider le lien. Il suffirait alors d’autoriser l’opération avec la biométrie, un code PIN ou un schéma.
Il est évident qu’à terme, ne plus avoir à gérer des dizaines, voire des centaines de mots de passe devrait être un vrai soulagement pour de nombreuses personnes, sans parler du gain de sécurité et de praticité. Même si, dans ce dernier domaine, tout n’est pas encore réglé, car les passkeys vont passer par une première période un peu « brute ».
… du moins à terme
Tout n’est pas clair en effet sur certains aspects de la synchronisation. Car si la sécurité semble être bien présente, avec un chiffrement de bout en bout et donc aucun autre accès que pour la personne détentrice de l’identité, que se passe-t-il quand on décide de changer de crémerie ?
La question se pose d’autant plus qu’en dehors du scénario classique « passer d’iOS à Android » (ou l’inverse), peu de personnes (proportionnellement) utilisent un seul écosystème. Beaucoup ont par exemple un smartphone Android avec un PC sous Windows, et il n’existe pas à l’heure actuelle de moyen simple de basculer les clés de l’un à l’autre.
C’est ce qui ressortait d’un article du Monde en septembre. Des procédures sont prévues, mais elles impliquent de transférer les clés l’une après l’autre. Aucun mécanisme de masse n’existe actuellement, ce qui n’est pas étonnant au vu de la jeunesse des dispositifs. Andrew Shikiar, directeur général de la FIDO Alliance, indiquait alors que ce sujet faisait l’objet de « discussions très actives ».
Certains éditeurs ont une carte à jouer, comme on l’a vu récemment avec Chrome. La dernière version du navigateur prend en charge les passkeys sur Windows 11, macOS et Android. Lors de l’accès à un site supportant la fonction, Chrome pourra proposer automatiquement la création d’une passkey, qui s’enregistrera alors dans le Gestionnaire de mots de passe maison.
Comme expliqué par Google, l’utilisation de la passkey sur un ordinateur déclenchera une vérification sur le smartphone, à condition qu’il soit proche.
Chrome reste cependant un bon exemple, car le navigateur est si omniprésent qu’il représente un écosystème à lui seul. Les clés créées et stockées dans le navigateur sont ainsi accessibles sur presque toutes les plateformes où il est disponible, à l’exception notable de Linux et surtout Chrome OS, qui recevra la capacité l’année prochaine.
Précisons également que les gestionnaires peuvent s’adapter aux passkeys, puisqu’il s’agit d’un standard. Plusieurs l’ont déjà fait, dont 1Password et Dashlane, qui vont pouvoir se montrer encore très utiles pendant des années. Cette compatibilité prendra de l’ampleur, notamment sur Android, puisqu’il sera possible à l’avenir de déclarer un gestionnaire comme stockage par défaut pour les passkeys. Ils pourront ainsi assurer le lien avec d’autres plateformes.
Il est évident que la diffusion des passkeys ne va pas mettre fin aux mots de passe tout de suite. La cohabitation s’annonce longue, car il faut prendre en compte à la fois les changements d’habitude que cela implique – ce n’est pas parce que la fonction est disponible que les utilisateurs vont renoncer immédiatement aux mots de passe – et l’équipement lui-même. Il faut notamment des versions très récentes d’Android, iOS, Windows et macOS.
Les passkeys dans la pratique
Il y a pour l’instant peu de cas pratiques. La compatibilité est annoncée à droite à gauche, mais c’est bien l’année 2023 qui va voir l’explosion des passkeys. Il est nécessaire d’abord que toutes les plateformes et les grands logiciels transversaux comme les navigateurs s’y mettent, pour assurer le lien entre les écosystèmes, le temps que ceux-ci apprennent à communiquer.
La manière dont sont pour l’instant pensées les clés demande de faire un minimum attention. Chaque écosystème, donc chaque compte central (Apple, Google, Microsoft…) va synchroniser les informations sur les autres appareils, mais il faut s’assurer qu’au minimum un appareil soit toujours accessible avec ledit compte, sans quoi la validation d’accès ne pourra plus se faire et les passkeys seront perdues.
Une pression particulière va être mise sur le smartphone, dont l’importance va de nouveau être décuplée. Il sera de loin l’appareil le plus utilisé pour la validation, capable de faire le lien entre les autres. Si le Bluetooth n’est pas présent, un code QR pourra être scanné sur le nouvel appareil avec le smartphone.
Mais concrètement, qui est aujourd’hui compatible avec ces codes d’accès, d’identification ou de sécurité ? En ce qui concerne les plateformes, toutes les plus récentes d’Apple les prennent en charge, via le Trousseau. Chez Google, la compatibilité passe par Chrome, avec support (pour l’instant) de Windows, macOS, Android et iOS, mais avec certaines limitations sur les plateformes Apple. Comme dit, la compatibilité Chrome OS arrivera courant 2023. Chez Microsoft, Edge est compatible (Windows et macOS), tandis que Windows le sera courant 2023 lui aussi.
Concernant les services, ils ne sont pas légions pour le moment, mais leur nombre grandit lentement. Best Buy, Dropbox, Facebook, GitHub, Godaddy, Google, Microsoft, Twitter ou encore Wordpress. Nous avons par exemple activé avec succès une « clé de sécurité » sur un compte Twitter depuis un ordinateur.
La création de la clé passait par l’affichage d’un code QR, que nous avons scanné avec un iPhone, qui a renvoyé lui-même vers un panneau dédié demandant confirmation (avec biométrie, FaceID dans notre cas). Lors d’une nouvelle connexion au compte sur un MacBook Pro via Safari, ce dernier a demandé la confirmation de l’identité avec Touch ID.
L’exemple est représentatif, car même si Twitter est compatible avec ces « clés de sécurité », il permet de changer de méthode d’identification, jusqu’à revenir au simple SMS si besoin. Le cas illustre la période de cohabitation qui commence entre les passkeys et les autres méthodes.
À terme, il ne devrait plus y avoir que ces codes, avec on l’espère une utilisation transparente entre tous les appareils. Il s’écoulera cependant des années avant que le standard se répande partout et que l’ensemble des appareils le prenne en charge. On attend surtout la création de passerelles entre les trois gros écosystèmes, car les limitations actuelles pourraient freiner l’enthousiasme initial. Par exemple, Chrome est compatible avec le Trousseau sur iOS, mais pas sur macOS, lui interdisant de piocher automatiquement dans les passkeys. Ce n’est pas bloquant – un code QR sera affiché à la place – mais le cas montre le type de problème qui persistera pendant un temps.
Une fois que les bases seront posées, c’est ce type de cassure dans l’expérience utilisateur qui nécessitera du travail. Apple, Google et Microsoft travaillent de concert sous l’égide de l’alliance FIDO, mais on les imagine volontiers moins prompts à travailler sur l’idée d’un départ vers la concurrence. Or, ce sera la clé du succès pour les passkeys. Sans un lissage de ces frictions, elles risquent d’être considérées comme captives.
