Comment l’engouement excessif pour les passkeys risque de rendre les clés de sécurité inutiles

• Si la tendance consistant à définir et exiger les passkeys comme des resident keys se généralise, des clés de sécurité comme Yubikey, Feitian ou Nitrokey atteindront vite leurs limites à cause de leur espace de stockage restreint
• Un non-resident credential fonctionne de sorte que la Relying Party fournit un credential ID que la clé de sécurité déchiffre pour obtenir la clé privée propre à chaque RP, si bien que seul le master key est stocké dans l’appareil
• À l’inverse, un resident/discoverable credential stocke la clé privée elle-même dans la clé de sécurité, ce qui consomme un emplacement par compte ; Nitrokey en prend en charge 8, et Yubikey généralement 20 à 32
• Les clés de sécurité CTAP2.0 ne permettent pas de supprimer individuellement les resident keys : il faut réinitialiser complètement l’appareil, ce qui change aussi le master key et rend même les non-resident keys existantes inutilisables
• Si les services et bibliothèques exigent par défaut des resident keys, les utilisateurs ayant plus de 150 comptes devront gérer plusieurs clés de sécurité et des clés de secours, ce qui complique fortement le libre choix de l’authenticator souhaité

---

Pourquoi les resident keys sont au cœur du problème

• Au cœur des inquiétudes selon lesquelles l’engouement excessif autour des passkeys pourrait transformer les clés de sécurité en appareils obsolètes, on trouve les resident keys
• L’idée selon laquelle une clé de sécurité peut prendre en charge un nombre de comptes « illimité » repose souvent sur le modèle des non-resident credentials
• Comme les resident keys consomment réellement l’espace de stockage interne de la clé, les limites du matériel apparaissent immédiatement à mesure que le nombre de comptes augmente

Fonctionnement des non-resident credentials

• Avec un non-resident credential, la Relying Party transmet à la clé de sécurité, via le navigateur, un credential ID au moment de l’authentification
• Le credential ID est un blob chiffré que seule la clé de sécurité peut déchiffrer, et le résultat de ce déchiffrement est la clé privée dédiée à cette Relying Party
• La clé de sécurité signe ensuite le challenge avec cette clé privée déchiffrée, puis renvoie la signature au navigateur et à la Relying Party
• Dans cette architecture, la clé privée ne réside pas en permanence dans l’enclave sécurisée, et seule la master key est conservée dans la clé de sécurité
• Le credential ID est chiffré en AES-128 et protégé par HMAC, ce qui le rend difficile à altérer ou à déchiffrer depuis l’extérieur
  • L’article compare cela au fait que, si AES-128 était cassé au point de permettre de déchiffrer une clé privée sans la clé de sécurité, alors le chiffrement TLS ou SSH serait lui aussi attaquable

La différence des resident/discoverable credentials

• Une resident key, ou discoverable credential, repose sur un modèle où la clé privée est stockée dans la clé de sécurité
• Lorsque la Relying Party envoie une liste vide de credential IDs, la clé de sécurité recherche les clés utilisables pour ce RP, en sélectionne une, puis signe
• Ce modèle ne dépend donc pas d’un credential ID externe à déchiffrer avec une master key
• En contrepartie, chaque credential occupe de l’espace dans la clé de sécurité, si bien que le nombre d’emplacements de resident keys devient une limite réelle du nombre de comptes

userVerification est distinct de resident key

• Il existe une confusion selon laquelle un credential devrait nécessairement être resident pour imposer la userVerification, mais ces deux notions sont distinctes
• Une clé de sécurité ne se contente pas de vérifier la présence de l’utilisateur par un toucher ; elle peut aussi vérifier en interne un PIN ou une donnée biométrique pour confirmer qu’il s’agit bien du véritable utilisateur
• Ce comportement est contrôlé par le flag userVerification et fonctionne indépendamment de la résidence de la clé
• Ainsi, même sans resident key, un appareil peut être utilisé comme un authenticator multifactoriel autonome

Capacité de stockage des clés de sécurité et contraintes de CTAP

• Comme les resident keys sont stockées dans l’appareil, le nombre d’emplacements disponibles dans une clé de sécurité est déterminant
  • Nitrokey prend en charge 8 resident keys
  • Yubikey en prend généralement en charge 20 à 32
  • Certaines clés ne prennent pas du tout en charge les resident keys
• La version du standard CTAP implémentée par la clé de sécurité influence aussi fortement les possibilités de gestion
  • CTAP2.1 et CTAP2.1PRE permettent de gérer, mettre à jour et supprimer individuellement les resident keys
  • CTAP2.0 impose une réinitialisation complète de l’appareil pour supprimer une resident key
• Lors de la réinitialisation d’un appareil CTAP2.0, la master key est également réinitialisée, ce qui rend les non-resident keys existantes elles aussi inutilisables
• Beaucoup de clés de sécurité sont probablement encore en CTAP2.0, et chez Yubico, la version de CTAP dépend de la version du firmware

La diffusion du terme passkeys et de la définition en resident key

• En 2022, Apple a annoncé sur macOS/iOS une fonctionnalité de passkeys utilisant Touch ID et Face ID comme authenticator WebAuthn
• Le terme passkeys est jugé plus accessible pour les utilisateurs que « webauthn authenticator » ou « security key »
• Par la suite, plusieurs interprétations sont apparues alors même que le sens de passkeys n’était pas clairement stabilisé
  • La bibliothèque Rust WebAuthn et des implémenteurs de Relying Party ont défini les passkeys comme le nom de tout authenticator que l’utilisateur peut choisir
  • Certains membres de la communauté ont appelé passkeys des credentials synchronisés entre plusieurs appareils
  • Lors de la conférence FIDO Authenticate, une définition assimilant « passkey » à « resident key » est apparue, et FIDO a ensuite repris cette définition dans sa FAQ
• L’une des raisons pour lesquelles cette définition attire l’attention est son lien avec la fonctionnalité à venir des navigateurs, la conditional UI
  • Si le credential est une resident key, le nom d’utilisateur et le credential WebAuthn peuvent être proposés en autocomplétion
  • Cela permet une expérience où l’utilisateur n’a pas besoin de saisir lui-même son identifiant

Les problèmes utilisateurs créés par l’exigence de resident key

• Si des bibliothèques WebAuthn poussent à exiger une resident key pour chaque enregistrement, les clés de sécurité au stockage limité peuvent se remplir très rapidement
• Par exemple, si un gestionnaire de mots de passe contient plus de 150 mots de passe enregistrés, les convertir tous en resident keys nécessiterait au minimum 5 Yubikeys
• En tenant compte des sauvegardes, il pourrait falloir gérer 10 à 15 Yubikeys
• Cela aboutit à une mauvaise expérience pour les utilisateurs ayant choisi des clés de sécurité, et l’exigence de resident key dans les passkeys peut rendre l’usage même des clés de sécurité difficile
• Le marketing autour des clés d’authentification FIDO utilise des formules comme « stockage illimité de paires de clés » ou « aucune limite sur le nombre de comptes enregistrés », ce qui est vrai pour les non-resident keys mais entre en contradiction avec l’exigence de resident key
• L’un des objectifs du WebAuthn Work Group est de permettre aux utilisateurs de choisir librement l’authenticator qu’ils veulent, sans pénalité, mais l’imposition des resident keys va à l’encontre de cet objectif
• Parmi les types d’authenticator présentés comme aptes à bien fonctionner dans un environnement passkey figurent les passkeys Apple, les passkeys Android, les gestionnaires de mots de passe prenant en charge WebAuthn, Windows avec TPM 2.0, et les navigateurs basés sur Chromium sur macOS utilisant Touch ID comme un TPM

Pistes de réponse possibles

• Une option consiste à modifier le comportement de rk=preferred pour éviter la création de resident keys sur les clés de sécurité
  • Aujourd’hui, la Relying Party peut définir le niveau de demande de resident key sur discouraged, preferred ou required
  • Actuellement, rk=preferred crée une resident key même sur un authenticator itinérant comme une Yubikey, ce qui le fait se comporter en pratique de manière proche de rk=required
  • Si preferred était assoupli en « créer une resident key uniquement lorsque l’espace de stockage est illimité », Android/iOS créeraient des resident keys, tandis que l’espace de stockage des clés de sécurité ne serait pas consommé
  • Le WebAuthn WG reste pour l’instant réticent à ce changement, et une implémentation séparée côté navigateur dépendrait en pratique d’une décision de l’équipe Chrome
• Une autre approche consiste à demander aux bibliothèques passkey d’utiliser rk=discouraged
  • rk=required peut exclure les clés de sécurité
  • rk=discouraged peut empêcher les utilisateurs Android de bénéficier de la conditional UI
  • L’auteur estime toutefois que, puisqu’il existe déjà des moyens d’autocompléter le nom d’utilisateur, cela vaut mieux que d’exclure les clés de sécurité
• Il est aussi possible de demander à FIDO d’imposer une capacité de stockage des resident keys dans les critères de certification
  • Aujourd’hui, FIDO n’impose pas d’exigence de capacité de stockage aux appareils certifiés
  • Si FIDO veut promouvoir les resident keys, l’auteur estime que les appareils certifiés devraient pouvoir en stocker plusieurs milliers

Conclusion

• La tendance excessive à considérer les passkeys comme des resident keys risque d’empêcher, ou de rendre très difficile, pour les utilisateurs de clés de sécurité, le choix de l’authenticator qu’ils souhaitent utiliser en ligne
• Le problème ne vient pas tant des passkeys elles-mêmes que de l’application systématique d’une exigence de resident key à des clés de sécurité aux capacités de stockage et de gestion limitées

[GN⁺]

Commentaires sur Hacker News

• Ce n’est pas tout à fait la même question que le chiffrement lui-même, mais ma mère m’a appelé en panique parce qu’elle n’arrivait plus à accéder à Gmail. Il s’est avéré que Google avait automatiquement enregistré son nouveau téléphone Android comme passkey et en avait fait le mode de connexion par défaut, mais l’interface était extrêmement déroutante
  Attendre des gens qu’ils comprennent ce qu’est une passkey, ou qu’ils sachent qu’il faut cliquer sur la deuxième option pour se connecter avec un mot de passe, c’est excessif. Google disait avoir « envoyé une passkey vers Android », mais aucune notification n’est apparue sur le téléphone, et même après 30 minutes, on n’avait toujours pas résolu le problème. Il était impossible de supprimer la passkey enregistrée automatiquement ou de désactiver ce flux d’authentification par défaut. L’UX de Google est épouvantable, et faire confiance à une version modifiée d’Android sur un téléphone Samsung d’entrée de gamme comme base d’un système d’authentification à grande échelle semble être une décision stupide

  • Google a le même problème avec la validation en deux étapes. Il affiche « Nous avons envoyé une notification au S21 », mais en réalité, même quand je tiens un S21 déverrouillé dans la main, une fois sur trois la notification n’arrive pas, ou bien seulement cinq minutes plus tard
    Ce n’est qu’un des nombreux problèmes récents que j’ai eus avec Google. Avant, j’évitais vaguement Google pour des raisons de vie privée ; maintenant, je fais tout mon possible pour réduire au maximum son usage. Mon entreprise a disparu de Google Maps sans raison, et il a fallu deux semaines pour la réinscrire, sans qu’il soit possible de parler à un humain. Chaque e-mail du support donne un numéro de téléphone, mais c’est celui du support publicitaire, qui ne peut rien faire pour un compte Business suspendu, et ils refusaient même de croire que l’équipe Google Business m’avait donné ce numéro pour obtenir de l’aide. J’ai dû répéter mes questions pendant 30 minutes avant qu’un agent du support Google Ads admette qu’il n’existe aucun moyen de parler à quelqu’un pour Google Business. Je suis désormais devenu un véritable évangéliste anti-Google
  • À cause de ces demandes de confirmation non sollicitées du type « nous avons envoyé une notification sur votre téléphone », j’envisage sérieusement de retirer mon activité de l’écosystème Google. Je comprendrais si j’essayais soudain de me connecter depuis l’autre bout du monde, ou si j’utilisais toujours Linux et que le navigateur était identifié comme Windows, mais avec un navigateur centré sur la confidentialité comme ungoogled chromium, cela se produit à chaque authentification, même depuis la même IP
    Et si le téléphone n’a plus de batterie ? Si vous l’avez perdu et que vous essayez de récupérer les identifiants des services de localisation en envoyant une réinitialisation de mot de passe par e-mail, mais que vous ne pouvez pas vous connecter à l’e-mail ? À partir de là commence la procédure « répondre aux questions ». Un algorithme opaque et irresponsable décide que Linux avec ungoogled chromium est suspect, et si vous vous souvenez mal de la réponse à des questions du type « quel pourcentage de l’espace de stockage disponible utilisez-vous actuellement ? », la récupération de l’accès relève alors de la chance. Pour information, je suis un utilisateur Google payant
  • Petite correction : la passkey n’est pas « envoyée » vers Android. La connexion à Gmail fonctionne en scannant avec Android le QR code affiché dans le navigateur afin de prouver qu’il détient la passkey
    Cela dit, je comprends parfaitement le fond du propos. L’UX et la terminologie sont déroutantes. Même si chaque étape fournit une explication, les gens ont appris, surtout dans l’urgence, à ignorer les petits textes d’aide et à cliquer sur le bouton le plus gros et le plus voyant, donc cela n’aide pas beaucoup. C’est un problème vraiment difficile en conception UX
  • Cette expérience m’a fait franchir une ligne. J’ai compris que Google ne prend pas ses décisions en fonction des utilisateurs. Google gagne son argent avec les annonceurs, fournit juste assez de service pour que les utilisateurs ne partent pas, et maintient juste assez pour bloquer les concurrents
    Tant que les utilisateurs ne s’en vont pas, Google ne s’en soucie pas, et n’a aucune raison de s’en soucier. Si vous voulez autre chose, il vous faut un service qui n’est pas financé par les annonceurs. Si Google exploite ses utilisateurs d’une certaine manière, Apple les exploite d’une autre ; choisir son poison n’est pas un vrai choix
  • Pour être juste, le problème ici ne vient pas vraiment des passkeys elles-mêmes, mais plutôt du fait que l’UX produit de Google est stupide. Si Google modifie soudainement l’UX de connexion d’une façon à laquelle les utilisateurs ne sont pas habitués, la plupart des gens seront forcément perdus

• Comme Apple ne l’a jamais vraiment défini, des penseurs ont comblé le vide pour les utilisateurs qui voulaient savoir : « mais au fond, qu’est-ce qu’une passkey ? »
  J’avais compris qu’Apple définissait les passkeys comme des paires de clés synchronisées via iCloud Keychain. Dans la présentation WWDC 2021, Apple distinguait aussi les passkeys des clés de sécurité en expliquant qu’on les « a toujours sur soi », c’est-à-dire grâce à la synchronisation entre appareils, et qu’elles sont « récupérables ». Depuis, la définition semble s’être élargie à d’autres formes de synchronisation cloud. Je pense que cet article fait un mauvais compromis. Les clés de sécurité ne sont pas importantes[1], parce qu’elles ne sont utilisées que par un très petit nombre d’utilisateurs techniques et par quelques entreprises qui prennent vraiment la sécurité au sérieux. Si l’on veut améliorer la sécurité du Web, il faut faire sortir les gens des mots de passe, et 99 % de la population n’utiliseront jamais de clés de sécurité à moins d’y être forcés. Les passkeys ont de fortes chances de remplacer les mots de passe, notamment grâce à leur intégration profonde dans les systèmes d’exploitation. Il ne faut pas optimiser l’authentification en fonction du fait que moins de 1 % des utilisateurs manquent d’emplacements pour clés résidentes. [1] Je possède 3 Yubikey, 3 clés de sécurité Yubico et 1 SoloKey

  • L’objectif n’était pas un produit Apple Passkey, mais une initiative à l’échelle de l’industrie. Au moment de son lancement en 2022, la définition s’était assouplie au point de ressembler davantage à une « expérience » offrant, par exemple, la découvrabilité et des options de vérification utilisateur
    L’utilisateur peut choisir d’utiliser un fournisseur de passkeys offrant sauvegarde et récupération, et la partie de confiance reçoit ce signal. Elle peut ensuite s’en servir pour décider s’il faut proposer la suppression de l’option de connexion par mot de passe
  • Les passkeys sont en fait définies par la FIDO Alliance
    Selon le standard FIDO, les passkeys remplacent les mots de passe et permettent de se connecter plus rapidement, plus facilement et de façon plus sûre aux sites web et aux applications sur les différents appareils de l’utilisateur. Contrairement aux mots de passe, les passkeys sont toujours robustes et résistantes au phishing. https://fidoalliance.org/passkeys/

• Je ne comprends pas pourquoi rk=required existe. Cela n’aurait jamais dû être une option au départ
  C’est précisément pour ce genre de choses que je continue à m’inquiéter des passkeys et de leur écosystème, et à les regarder avec scepticisme. Ceux qui les conçoivent ont la responsabilité de concevoir le protocole de façon à ce qu’il ne devienne pas un outil idéal pour toutes sortes de pratiques de marché abusives permettant à de grandes entreprises comme Microsoft de ruiner gravement la sécurité et l’interopérabilité tout en tuant la concurrence. Pourtant, l’attitude montrée à répétition dans les articles et les billets ressemble plutôt à « allez vous faire voir, on va rendre les abus encore plus faciles ». Ce n’est pas seulement un problème de clés résidentes ; par exemple, la manière dont l’attestation est traitée peut elle aussi être facilement détournée pour nuire aux entreprises

  • L’objectif ici semble être de faire du téléphone le passkey, et de ne plus rien utiliser d’autre. Vu sous cet angle, tout ce qui est décrit dans l’article prend sens
  • Je trouve que c’est moins grave que l’abus d’attestation
    Si un service définit rk=required mais que la plateforme ne veut pas l’activer, ne le prend pas en charge ou ne le peut pas, la procédure échouera systématiquement et l’inscription elle-même sera impossible. Si le but est d’intégrer des utilisateurs et de développer l’activité, cela ressemble à un choix contre-productif
  • Je me demande quel est exactement le problème derrière « la manière dont l’attestation est traitée peut être détournée pour tuer facilement des entreprises »

• Je ne travaille pas du tout dans la sécurité ou la cryptographie, donc cet article a été très difficile à suivre, et j’imagine que ce sera pareil pour d’autres
  Pour quelqu’un qui a déjà les connaissances nécessaires, mes questions paraîtront peut-être étranges, mais je bloque toutes les une ou deux phrases. Je ne comprends ni comment ni pourquoi « au final, tout se ramène aux clés résidentes », ni le lien avec les passkeys ou les HSM. Quand il est dit qu’« il faut comprendre ce que sont les clés découvrables / résidentes », je ne sais pas si cela veut dire que toutes les clés résidentes sont découvrables, que toutes les clés découvrables sont résidentes, ou les deux. Quand l’article dit qu’« on a sans doute vu que la plupart des clés prennent en charge un nombre “illimité” de comptes », je ne sais pas si « clés » désigne les passkeys, les clés stockées dans un HSM, ou les deux. Et quand il est dit qu’« une clé enveloppée par une clé est envoyée à la clé de sécurité », je ne comprends pas non plus si cela veut dire qu’un HSM peut s’appliquer à un nombre illimité de comptes parce qu’il peut stocker une clé en l’enveloppant avec une autre

  • Le point essentiel semble être que WebAuthn est poussé vers un modèle de passkey où chaque site crée des identifiants qui consomment de l’espace de stockage. Le nom de site affichable, le nom du compte utilisateur, le handle de l’enregistrement utilisateur, la clé privée et d’autres éléments consomment tous du stockage
    Un téléphone peut stocker 10 000 passkeys sans problème, mais une clé matérielle moderne peut n’avoir de la place que pour 25 au total dans sa mémoire flash disponible. Si cet espace est nécessaire, c’est à cause de la découvrabilité. Par exemple, sur la page de connexion de GitHub.com, si vous choisissez la prise en charge d’un nouveau passkey, vous pouvez vous connecter sans même saisir le nom du compte. Le navigateur offre une expérience de type gestionnaire de mots de passe, et comme un mot de passe dans un gestionnaire, un passkey devient localement un enregistrement de compte pour un site. Mais WebAuthn a aussi plusieurs modes qui ne sont pas des passkeys. Les identifiants non découvrables exigent qu’une liste de handles soit fournie pour un compte utilisateur donné, handles que la clé a fournis lors de l’enregistrement. Lors de l’authentification, seules les informations d’identification correspondant à ces handles sont proposées. Les clés de sécurité matérielles exploitent cela pour stocker, dans le handle lui-même, les informations nécessaires aux opérations cryptographiques futures, et ce mode n’utilise pas l’espace de stockage flash. Une fois le nom d’utilisateur saisi, une API renvoie la liste des handles, qui peut être appliquée à la clé de sécurité pour permettre l’authentification sans limite de stockage. Cela dit, beaucoup de sites adoptent une politique consistant à ne pas révéler l’existence d’un compte. On a tous vu des procédures de récupération du type « si ce compte existe, vous recevrez bientôt un e-mail ». Du point de vue d’un site, fournir dans le flux de connexion une API qui permettrait de détecter s’il existe un compte lié à un nom d’utilisateur ou à une adresse e-mail, et combien d’identifiants y sont enregistrés, peut être difficile à accepter. Au final, plutôt que de voir les sites adopter largement cette procédure au point d’influencer les limites matérielles actuelles, il semble plus probable qu’on voie apparaître des clés de sécurité avec 10 fois plus de stockage
  • Je suis d’accord pour dire que l’argumentation de l’article est mauvaise. L’idée principale est que la possibilité, dans le protocole WebAuthN, pour la relying party de spécifier rk=required est nuisible. Cela empêche beaucoup de matériel TPM de fonctionner comme portefeuille ou base de données de passkeys
    Je pense que la plupart des commentaires sont d’accord là-dessus. Cela ne justifie pas pour autant la confusion créée par l’auteur en consacrant la moitié de l’article à débattre de la définition d’un passkey
  • L’article suppose pas mal de connaissances préalables sur FIDO2, donc il est normal qu’il soit déroutant
    Les passkeys sont implémentés au-dessus de FIDO2, en particulier en utilisant la fonctionnalité de clé résidente de la spécification FIDO2. Les dispositifs matériels d’authentification FIDO2 ne sont pas exactement des HSM, mais ils s’en rapprochent, et certains appareils comme les Yubikey sont à la fois des HSM et des dispositifs d’authentification FIDO2. Dans FIDO2, « clé résidente » et « clé découvrable » sont synonymes. La spécification emploie « clé résidente », mais « clé découvrable » est aussi couramment utilisé ; c’est l’un des termes confus créés par FIDO. Ici, « clé » ne désigne pas un passkey ni une clé stockée dans un HSM, mais un dispositif matériel d’authentification FIDO2 comme une Yubikey, souvent appelé « clé de sécurité ». Les dispositifs matériels d’authentification FIDO2 peuvent être enregistrés pour un nombre illimité de comptes parce que, tant qu’ils n’utilisent pas de clés résidentes, ils sont essentiellement sans état et ne stockent rien. Lors de l’enregistrement d’un compte, l’appareil génère une paire de clés de type EdDSA, mais ne la stocke pas ; il chiffre la clé privée avec une clé maître intégrée, par exemple une clé AES256. Il envoie ensuite à la relying party, comme google.com, la clé publique en clair et la clé privée chiffrée, autrement dit la clé « enveloppée », afin qu’elle la stocke. Lors de l’authentification, la clé privée chiffrée, c’est-à-dire la clé « enveloppée », est renvoyée au dispositif d’authentification, déchiffrée dans l’appareil, puis utilisée pour produire une signature numérique. Cela dit, FIDO2 ne spécifie pas réellement comment les clés non résidentes doivent être implémentées, et les clés enveloppées ne sont qu’une méthode parmi d’autres. FIDO2 exige seulement que la clé privée puisse être dérivée de manière sûre à partir de l’ID d’identifiant ; cet ID est une donnée arbitraire qui peut être une clé enveloppée, ou non

• Je trouve que c’est une vision trop sévère de la situation. Si l’on veut profiter des avantages d’une nouvelle norme d’authentification qui élimine les mots de passe faibles et leur réutilisation, et empêche 99 % des compromissions de comptes au quotidien, on peut aussi considérer qu’il faut simplement abandonner une ancienne YubiKey qui tenait depuis 2013 et dépenser 30 dollars pour passer à un modèle plus récent

  • Je ne vois pas pourquoi on devrait être forcé de faire cette mise à niveau. Les clés non résidentes éliminent elles aussi les mots de passe faibles et leur réutilisation. Les clés résidentes n’apportent qu’une petite amélioration supplémentaire : une fois la clé branchée, le service sait à quel compte elle correspond. Cela ne me semble pas être une raison valable pour jeter tous les dispositifs d’authentification existants actuellement utilisés
  • En regardant le manuel technique de la série 5, il semble qu’elle n’en prenne en charge que 25. Pour l’instant je n’en ai que 2, mais j’ai bien plus de 25 TOTP
    Je ne sais pas ce qu’il en est du modèle Bio FIDO, mais si c’est similaire, YubiCo n’a peut-être pas de produit réellement adapté à un grand nombre de clés résidentes. Correction : Bio a la même limite de 25
  • Je trouve au contraire que c’est une interprétation trop charitable
    Des clés résidentes partagées ne devraient pas exister, sauf pour un usage temporaire de très courte durée. C’est une charge en matière de responsabilité, un risque de sécurité, et cela encourage de mauvaises pratiques de sécurité. Le meilleur exemple est le TOTP, très défaillant du point de vue de la sécurité. On ne devrait pas vouloir partager ou sauvegarder un secret partagé sur plusieurs appareils, mais comme c’est possible, et que les implémentations bâclées de l’authentification à deux facteurs sont devenues la norme plutôt que l’exception, on y est de fait poussé. Vu la direction actuelle, les passkeys semblent prendre le même chemin, avec les mêmes défauts et la même hostilité envers l’utilisateur
  • Malgré tout, cela ne change pas grand-chose au fond. Ma clé ne peut stocker que 25 clés résidentes, alors que j’ai plus de 25 mots de passe enregistrés dans mon gestionnaire de mots de passe
  • Je crains qu’à l’avenir on n’ait plus d’autre choix que d’accepter cet « avantage ». Quand un site implémente cette nouvelle norme d’authentification, va-t-il continuer à conserver en alternative l’actuel identifiant/mot de passe/authentification à deux facteurs ?

• Une authentification basée sur « quelque chose que l’on possède mais que l’on peut perdre » est fondamentalement cassée. Si vous perdez l’appareil, vous perdez l’accès, ou bien il faut qu’il existe ailleurs un maillon plus faible, ce qui annule l’intérêt de cette sécurité supposément supérieure

  • Il suffit d’imprimer des codes de secours ou d’ajouter une deuxième clé de tiroir. L’idée en elle-même est excellente, mais le marketing est très mauvais, le parcours de configuration est étrange pour les utilisateurs ordinaires, et pousser des clés compatibles AirDrop ou synchronisées via le cloud est aussi une mauvaise idée. Le problème le plus important reste le coût des clés
  • Les mots de passe n’entrent-ils pas eux aussi dans cette catégorie ? Les gens perdent aussi souvent leurs mots de passe
    On verra ce que donnent les résultats, mais si les passkeys sont largement adoptées, il me semble que, pour la majorité des gens, les blocages de compte deviendront moins fréquents plutôt que plus fréquents

• Je me demande pourquoi la capacité de stockage des clés matérielles est aussi limitée. Combien cela coûterait-il en plus d’y intégrer un stockage de masse accessible par le processeur sécurisé ?
  Ce stockage de masse serait bien sûr fortement chiffré par le processeur sécurisé, et la clé de chiffrement serait elle aussi effacée quand tout est supprimé

  • Parce qu’un stockage inviolable sûr coûte cher
    Du point de vue de la sécurité, on peut même dire qu’une clé de sécurité sans aucun stockage est la meilleure clé de sécurité possible. Les protocoles qui injectent et stockent des secrets de sécurité, des clés de sécurité ou d’autres éléments dans une clé de sécurité, une enclave sécurisée, etc., au lieu de les dériver de secrets partagés, ont en général présenté de graves défauts. Parfois il s’agit d’un défaut de sécurité fondamental, comme avec le TOTP ; parfois c’est un défaut de complexité. De la même manière, il ne faut absolument pas vouloir partager des clés de sécurité HSK / 2FA entre plusieurs appareils. Si un appareil fuit, tout est compromis. Il faut au contraire une clé distincte pour chaque appareil, et cet overhead est négligeable dans l’ensemble pour le fournisseur de connexion ou côté serveur
  • Cela ressemble à un choix de conception délibéré pour garder ces appareils aussi « stupides » que possible. Dès qu’on ajoute du stockage, on ouvre la même surface de vulnérabilité que sur n’importe quel autre support de stockage ; ensuite viennent les capacités de calcul, et au final on n’a plus une YubiKey simple mais un ordinateur complet
  • On pourrait sans doute augmenter le stockage, mais plus on en met, plus le risque de panne augmente. Les clés actuelles supportent un usage assez rude avant de cesser de fonctionner
    Un faible volume de stockage a aussi l’avantage d’être un peu plus facile à auditer. Bien sûr, même cette petite taille pousse peut-être déjà, avec les standards actuels, au-delà de ce qu’il est réaliste d’auditer
  • Plutôt que d’être limité par la mémoire, c’est presque conçu pour ne pas avoir de limite mémoire
    Si l’on regarde les TPM, à chaque signature les entrées sont les données à signer et la clé privée scellée. La clé scellée est la clé privée générée par le TPM, chiffrée symétriquement avec une clé intégrée au TPM. Cette clé scellée est stockée sur un stockage de masse, puis fournie au TPM à chaque opération de signature. Grâce à cette conception, on peut avoir autant de clés que le permet le stockage de masse
  • On pourrait aussi imaginer un système modulaire. Par exemple, vendre un produit qui ressemble à une clé USB, mais avec à l’arrière un emplacement dans lequel on insère une petite clé de sécurité au format type YubiKey Nano
    Une fois la clé de sécurité insérée dans l’emplacement, la clé USB fournit le stockage à la clé de sécurité et apparaît à l’ordinateur comme une clé de sécurité. Quand aucune clé de sécurité n’est insérée, l’appareil fonctionne comme une simple clé USB. On garderait la clé de sécurité branchée au quotidien, puis si l’on a besoin de plus de stockage, il suffirait d’acheter un module de stockage plus grand, de retirer la clé de sécurité du module existant, de le brancher à l’ordinateur pour copier les fichiers chiffrés, puis de les transférer vers le nouveau module avant de réinsérer la clé de sécurité

• Au départ, je ne suis pas sûr que ce soit une bonne idée d’utiliser une clé de sécurité physique comme passkey. Les passkeys ont été conçues comme remplaçants du mot de passe et, pour cela, elles semblent généralement avoir besoin de la propriété à deux facteurs qu’offrent les téléphones ou les ordinateurs de bureau, qui exigent, en plus de « quelque chose que l’on possède », « quelque chose que l’on sait » ou « quelque chose que l’on est » pour le déverrouillage
  À mon avis, il vaut mieux conserver les clés de sécurité physiques comme second facteur d’authentification, en plus des passkeys, dans certains contextes à haute sécurité. C’est particulièrement vrai lorsque la résistance à la duplication est une fonctionnalité essentielle. Dans cet usage, on connaît déjà le compte auquel on tente de se connecter au moment d’atteindre la deuxième étape, donc une clé résidente n’est pas nécessaire. Je pense aussi que la fonction d’autocomplétion offerte par les clés résidentes est importante pour l’UX des passkeys. La sacrifier pour maintenir une rétrocompatibilité avec une minorité de clés réservées aux passionnés de sécurité n’a pas de sens. Bien sûr, s’il existe un moyen de conserver cette UX sans clé résidente, alors très bien

  • Je pense globalement la même chose. L’idée vers laquelle tout le monde converge aujourd’hui est d’avoir un coffre-fort de sécurité chiffré localement et digne de confiance, puis de devoir prouver son identité auprès de ce système. Cela peut se faire par mot de passe ou par clé
    Il est plus facile de croire que le gestionnaire de mots de passe que l’on a choisi est plus sûr que de supposer que tous les services du monde où l’on crée un compte sont sûrs ou impossibles à phishing. Ainsi, quand on en arrive à utiliser des passkeys, on se trouve souvent déjà dans un contexte plus sûr, où son identité a été établie auprès du système d’exploitation ou d’un gestionnaire de mots de passe possédant les passkeys. De plus, les services qui ne prenaient pas en charge les clés matérielles jusqu’à présent, ou jusqu’à récemment, risquent fort de ne pas les prendre en charge dans un avenir proche non plus. À l’inverse, une solution de passkeys est bien plus facile à adopter, car le coût d’intégration se limite à peu près au support logiciel, ce qui peut offrir un bien meilleur retour sur investissement. Bien sûr, cela concerne surtout les sites web, et les passkeys se rapprochent d’une « clé SSH standardisée » pour les sites web. Les clés matérielles semblent plus utiles comme second facteur pour ouvrir réellement le coffre contenant les passkeys, et, dans ce cas, un mot de passe peut aussi être nécessaire. Il me semble que les clés matérielles ont encore un peu de temps devant elles. Après avoir essayé comme méthode principale sur GitHub, Gmail, etc., le flux de connexion par passkey est vraiment excellent
  • Les gestionnaires de mots de passe ont déjà rendu les mots de passe inutiles. À part un seul mot de passe maître, je ne connais aucun de mes mots de passe. Les passkeys sont une solution inutilement complexe à un problème dont nous n’avons pas vraiment besoin
    Il suffirait que le navigateur expose une API HATEOAS simple à laquelle les gestionnaires de mots de passe puissent se connecter, et que l’application web expose le HTML qui déclenche le navigateur. Le gestionnaire de mots de passe déciderait alors comment authentifier l’utilisateur, c’est-à-dire selon la méthode voulue par l’utilisateur, puis injecterait automatiquement le secret du site web, ce qui connecterait l’utilisateur automatiquement. En cas de problème, on pourrait utiliser une réinitialisation par e-mail. Je comprends que, du point de vue des sites web qui veulent une « sécurité très sophistiquée », ils souhaitent quelque chose de plus complexe. Mais l’utilisateur devrait pouvoir activer de manière optionnelle un niveau de sécurité plus élevé. Par exemple, pour la plupart des sites web, un simple hash de mot de passe suffit si l’on part du principe que le gestionnaire de mots de passe utilise un mot de passe aléatoire. N’importe quel site peut implémenter cela, n’importe quel gestionnaire de mots de passe peut l’implémenter, et c’est meilleur que l’usage actuel des mots de passe pour 99 % des utilisateurs ordinaires. Cela peut servir de méthode d’authentification par défaut. Ensuite, si l’on veut du TOTP, de l’OIDC, de la cryptographie à clé publique, etc., le serveur peut l’annoncer et le client peut choisir d’y participer pour poursuivre l’authentification. Il n’est pas nécessaire que tous les sites et tous les utilisateurs emploient la méthode la plus sûre. Il faut d’abord faciliter l’élévation du niveau de base de la sécurité, puis laisser les gens choisir progressivement une sécurité plus forte
  • Lorsque j’utilise une authentification sans mot de passe (FIDO2) avec une YubiKey, l’appareil demande un PIN avant de demander de toucher le dispositif. Si l’on se trompe trop souvent de PIN, la YubiKey se bloque et il faut réinitialiser l’appareil, ce qui invalide tous les enregistrements existants où cette clé était utilisée pour l’authentification
    Si quelqu’un vole mon jeton matériel, cela ne me semble pas être un gros problème. https://support.yubico.com/hc/en-us/articles/4402836718866-U...
  • En y réfléchissant, le problème fondamental peut se formuler comme « authentifier une existence biologique auprès d’un système électronique »
    Avec les mots de passe, l’interface d’authentification est le clavier, et il n’existe aucune garantie réelle que la personne qui saisit le mot de passe soit bien celle qu’elle prétend être. Les mots de passe reposent sur une connaissance facile à transmettre, qui peut donc être extraite de nombreuses façons. Il vaut bien mieux déplacer l’interface d’authentification vers une relation appareil-à-appareil. Au lieu de supposer qu’une connaissance facilement transmissible n’a pas été transmise, on suppose qu’un être biologique est capable de gérer son dispositif d’authentification, et les humains sont naturellement assez doués pour cela. On peut aussi renforcer le système en augmentant le nombre de canaux d’authentification, et limiter l’authentification entre l’être biologique et l’appareil utilisé pour l’authentification du système distant, comme avec FaceID. Au fond, il semble naturel de supposer qu’un appareil comme un téléphone ou une clé représente cette personne. À la maison, nous partageons non seulement le mot de passe Netflix, mais aussi une carte de crédit. Pour des raisons pratiques, nous laissons une carte avec la clé de secours, afin que n’importe qui puisse l’utiliser s’il faut acheter quelque chose pour la maison. Nous nous faisons confiance pour bien l’utiliser, et tout le monde connaît le PIN, même s’il sert rarement puisque le paiement sans contact est courant. C’est bien plus naturel que de suivre toutes les dépenses puis de faire les comptes plus tard. C’est probablement illégal et la banque annulerait sans doute la carte si elle l’apprenait, mais bon. Les systèmes informatiques ont un besoin urgent de se rapprocher du comportement humain en fonctionnant d’une manière analogue au monde réel. Comme nous sommes impliqués dans les systèmes informatiques, la plupart d’entre nous tiennent le coup, mais les personnes peu à l’aise avec la technologie ont déjà du mal avec des questions quotidiennes comme quel est le mot de passe de l’iPhone, quel est celui d’iCloud, quel est celui de Gmail, ou pourquoi il faut saisir un code dans WhatsApp. En réalité, moi non plus je n’ai pas compris Mastadon. Je serais probablement sans défense face au phishing sur Mastadon, et je pense que je saisirais n’importe quoi si l’écran me demandait de le faire
  • Dire que les passkeys sont des remplaçants du mot de passe n’est pas juste

Les passkeys, comme leur nom l’indique, parasitent la norme FIDO2 U2F conçue à l’origine comme second facteur. Les clés résidentes servent à l’authentification à deux facteurs sur l’appareil avec un PIN, et constituent un remplacement fonctionnel des smart cards. Quelqu’un, probablement Apple, a apparemment estimé que WebAuthn suffisait à lui seul pour devenir l’unique facteur d’authentification. Il n’y a ni clé résidente ni ancrage matériel, et les clés circulent via iCloud, tout en étant présentées comme protégées sur l’appareil par Touch ID/Face ID. Et cela a été rebaptisé passkey. L’authentification à deux facteurs n’est pas une fin en soi. L’objectif est une authentification utilisateur résistante au phishing, à la force brute et au credential stuffing, sans être aussi difficile à déployer que les smart cards. FIDO2 y parvient. Le problème des implémentations d’Apple, Google et Microsoft n’est pas une faiblesse de la sécurité au niveau du protocole entre le site d’authentification et l’appareil de l’utilisateur. Le protocole est le même. Le problème, c’est que le site doit désormais faire confiance au compte de plateforme personnel de l’utilisateur, supposer qu’il est correctement configuré, et croire que la plateforme continuera toujours à se comporter correctement à l’avenir et à gérer convenablement les attaques visant le compte personnel de l’utilisateur.

• Pour ajouter du contexte, je dirige une entreprise d’authentification sans mot de passe soutenue par YC, et nous l’avons déployée dans de grandes organisations. Il semble clair que les passkeys seront la réponse pour l’authentification sans mot de passe côté grand public, mais cela ne semble pas encore se refléter dans l’environnement des entreprises
  Les passkeys sont excellentes pour les consommateurs. En effet, elles visent à permettre un accès de secours autonome en sauvegardant les identifiants sur d’autres appareils, via le backup par défaut d’iCloud ou des mécanismes comme AirDrop. Techniquement, les appareils qui reçoivent ces identifiants partagés ne peuvent pas fournir d’attestation. L’attestation est une « preuve » qu’une paire de clés a été générée sur un appareil précis, comme une YubiKey ou un appareil Apple. Des fabricants comme Yubico expédient leurs clés avec des paires de clés / certificats intégrés et non extractibles, et comme il n’existe aucune interface externe pour accéder à cette paire de clés, les administrateurs peuvent avoir un haut niveau de confiance dans le fait qu’il s’agit bien d’une vraie YubiKey. Quand il n’y a pas d’attestation et que la clé peut être partagée, on voit où les problèmes commencent. Les entreprises ne veulent pas assumer le risque qu’un identifiant transférable par AirDrop expose l’accès à des comptes employés privilégiés. Avec une YubiKey, le risque de vol numérique est pratiquement nul. Au final, les passkeys ne peuvent pas non plus servir à déverrouiller un appareil ou un serveur. FIDO2, et plus encore les développeurs de systèmes d’exploitation, ont encore beaucoup de chemin à parcourir avant d’en finir complètement avec les mots de passe. Aujourd’hui, sur la majeure partie du marché entreprise, c’est YubiKey qui comble ce vide, et certains ont dépensé des millions de dollars en matériel. Les passkeys, dans leur état actuel, seront difficiles à vendre

  • Les passkeys ne sont pas un terme technique, mais un terme d’expérience. C’est pourquoi leur utilisation dans une argumentation technique s’effondre en partie
    Apple prend en charge les passkeys, Android et Chrome aussi, Microsoft aussi, et YubiKey aussi. Mais les fonctionnalités et contraintes, comme les procédures d’authentification pour la vérification de l’utilisateur ou la possibilité de duplication, peuvent varier fortement. Une administration peut prendre en charge les passkeys, mais ne les autoriser que lorsqu’elles sont fournies par un authentificateur certifié FIPS répondant aux exigences AAL2. Ce ne sera pas, du moins pour l’instant, quelque chose venant d’Apple ou de Google. Une entreprise peut choisir de prendre en charge des passkeys générées via des logiciels et configurations fournis par un produit géré par MDM, et Apple a annoncé un support bêta à ce sujet. En revanche, si un service public destiné aux citoyens tente d’imposer un authentificateur matériel spécifique, cela risque d’être très pénible. Il est déjà difficile de convaincre les citoyens d’acheter un matériel à plus de 80 dollars, et comme les technologies du web sont conçues autour du choix de l’utilisateur, il est peu probable que l’API WebAuthn et l’expérience utilisateur soient optimisées pour aider à restreindre ce choix
  • Que se passe-t-il si Google ou Apple bloque un compte par erreur pour des raisons absurdes comme l’anti-bot ou la détection de fraude ?
  • les YubiKeys 5 peuvent être utilisées comme passkeys

• Du point de vue de la sécurité, je trouve que c’est une solution vraiment médiocre
  C’est une structure de rêve pour les gouvernements et pour des entreprises comme Apple ou Google afin de contrôler la vie numérique. Avec les mots de passe, on est dans une situation proche d’un système sans état : même si vous traversez une frontière avec un compte e-mail personnel ou n’importe quel autre compte, personne ne peut savoir que vous possédez ce compte, et il est difficile de vous forcer à donner l’accès, d’extraire les éléments d’accès du matériel ou de vous verrouiller en prétendant que vous avez perdu l’accès à l’appareil. Même si une clé maître ou autre est stockée dans un TPM ou un élément sécurisé, pour certains gouvernements ce n’est qu’une question d’années et de puissance de calcul. Dans bien des cas, cela constitue aussi en soi une preuve que vous détenez les identifiants d’un compte précis. Les fabricants d’appareils ou de systèmes d’exploitation peuvent facilement être contraints par les autorités de fournir l’accès à la zone sécurisée, que ce soit volontairement ou non.