- Google propose désormais les clés d’accès comme option par défaut pour les Google Account personnels, afin de faciliter la transition vers une connexion sans mot de passe
- À partir de la prochaine connexion, une invite à créer et utiliser une clé d’accès s’affichera, et l’option « Skip password when possible » apparaîtra activée dans les paramètres du compte
- Les clés d’accès permettent de se connecter avec les méthodes de déverrouillage de l’appareil — empreinte digitale, reconnaissance faciale ou code PIN — et Google estime qu’elles sont 40 % plus rapides que les mots de passe et plus sûres grâce à leur fonctionnement cryptographique
- La connexion par mot de passe restera disponible pour le moment ; les utilisateurs qui ne le souhaitent pas peuvent désactiver « Skip password when possible » pour refuser l’utilisation des clés d’accès
- Les clés d’accès sont déjà utilisées dans YouTube, Search et Maps, Uber et eBay les prennent aussi en charge, et la compatibilité avec WhatsApp devrait arriver prochainement
Changement du mode de connexion par défaut pour les Google Account personnels
- Après avoir lancé plus tôt cette année la prise en charge des clés d’accès, Google estime que les retours des utilisateurs ont été positifs
- Les clés d’accès sont désormais proposées comme option de connexion par défaut sur l’ensemble des Google Account personnels
- Lors de la prochaine connexion au compte, une invite s’affichera pour créer et utiliser une clé d’accès
- Dans les paramètres du Google Account, l’option « Skip password when possible » apparaîtra activée
Fonctionnement des clés d’accès et caractéristiques de sécurité
- Les clés d’accès utilisent, lors de la connexion à un compte, les mêmes méthodes que le déverrouillage de l’appareil : empreinte digitale, reconnaissance faciale ou code PIN
- Selon Google, la connexion avec une clé d’accès est 40 % plus rapide qu’avec un mot de passe
- Elle s’appuie sur la cryptographie, ce qui la rend plus sûre, et elle offre aussi une résistance au phishing
- Les utilisateurs peuvent ainsi réduire la charge liée à la mémorisation de chiffres et de caractères spéciaux dans les mots de passe
Les mots de passe et le choix des utilisateurs restent disponibles
- Google estime qu’il faut du temps pour qu’une nouvelle technologie s’installe, et que les mots de passe pourraient donc rester présents pendant un certain temps
- Les utilisateurs peuvent toujours se connecter avec un mot de passe
- Les utilisateurs qui ne veulent pas de clés d’accès peuvent désactiver l’option « Skip password when possible »
La prise en charge des clés d’accès s’étend au-delà de Google
- Depuis le lancement des clés d’accès, les utilisateurs les emploient dans des applications Google comme YouTube, Search et Maps
- Google voit positivement la progression de l’adoption des clés d’accès dans l’ensemble du secteur
- Uber et eBay proposent une option permettant de se connecter à leur plateforme sans utiliser de mot de passe
- La compatibilité avec WhatsApp devrait également être proposée prochainement
Prochaine étape vers la connexion sans mot de passe
- Google continuera d’indiquer où il est possible d’utiliser des clés d’accès pour d’autres comptes en ligne
- L’entreprise encourage le secteur à passer aux clés d’accès afin de réduire l’usage des mots de passe et, à terme, de les rendre rares
- Les informations relatives à la sécurité des comptes Google sont disponibles sur myaccount.google.com/safer
1 commentaires
Avis de Hacker News
Comme plusieurs personnes l’ont dit, si l’on perd son appareil, il est très difficile de relancer une authentification cryptographique
Le mois dernier, ma femme a cassé la vitre de son iPhone et l’a fait réparer via AppleCare, mais Apple ne nous avait pas dit qu’une « réparation de vitre » impliquait en pratique le remplacement de composants internes et une réinitialisation
Les sauvegardes Apple de l’iPhone ne contiennent pas les secrets cryptographiques comme l’eSIM
Au final, pour activer l’eSIM, il faut l’e-mail ; pour accéder à l’e-mail, il faut MS Authenticator ; et MS Authenticator ne peut pas être activé sans SMS : on se retrouve dans une boucle
Il a fallu aller en boutique chez l’opérateur avec tout un tas de pièces d’identité avec photo pour faire réémettre l’eSIM, et même avec le bon mot de passe, un verrouillage matériel du téléphone a fini par bloquer le compte bancaire
La résolution a pris plusieurs jours et a nécessité de se rendre physiquement dans plusieurs organismes. Si cela nous était arrivé pendant un voyage à l’étranger, nous aurions été complètement bloqués
Les temps ont changé : désormais, toute l’identité numérique tient dans une smart card à l’intérieur du téléphone. Que cette smart card soit une SIM ou une puce TPM intégrée, si on la perd, aux yeux des autres on est pratiquement mort
Les passkeys aggravent énormément ce problème. Avec une SIM physique, on peut au moins la déplacer d’un téléphone à un autre, mais une passkey ne peut pas être transférée d’un fournisseur à l’autre
Il faut s’enfuir en hurlant. Ne croyez pas le battage médiatique, et attendez que les fournisseurs proposent de vraies solutions de transfert et de récupération
Les gens détestent les mots de passe, mais dans la réalité, pour beaucoup de situations et de modèles de menace, ils restent le meilleur compromis. Si l’on tire au moins 32 octets depuis
/dev/randomet qu’on les encode comme on veut, personne dans cet univers ne pourra les casser par force brute, et un gestionnaire de mots de passe règle aussi le problème de la réutilisationEn plus, cela a l’avantage de me laisser contrôler le mode de stockage et de mettre en place autant de sauvegardes redondantes qu’il m’en faut pour être rassuré
Les sauvegardes iPhone incluent une sauvegarde des éléments stockés dans iCloud Keychain, et on peut y accéder à nouveau si l’on dispose d’un autre appareil Apple ou d’une clé de récupération. Avec le code de l’appareil ou la clé de récupération, on peut tout réamorcer
L’eSIM est un cas particulier, car elle dépend de l’opérateur ; ce genre de chose a toujours été, et restera probablement, pénible parce que lié aux boutiques et aux appels téléphoniques
Pour ma part, j’en utilise presque toujours trois : une YubiKey sur mon poste de travail, une YubiKey portable et mon téléphone. Ces trois éléments me permettent de relancer à la fois Google pour l’e-mail et Apple pour le téléphone. Le reste est dans 1Password et reste accessible via ces moyens
Même dans la pire des situations d’urgence, je pense que je pourrais récupérer mon e-mail d’une manière ou d’une autre. En vérifiant mon identité auprès de mon fournisseur DNS et en modifiant les enregistrements MX, je pourrais reprendre les choses en main. Cela dit, je ne considère pas forcément l’e-mail comme indispensable à la vie quotidienne. Perdre l’accès serait extrêmement pénible, mais pas une condamnation à mort
Mes contacts SMS et Signal existent aussi ailleurs, et je peux utiliser l’argent de mon compte bancaire en faisant des chèques. Pour les comptes liés au travail, je peux y accéder en me présentant physiquement au bureau
En revanche, je pense que les passkeys risquent d’être trop complexes pour l’utilisateur d’ordinateur moyen. Malheureusement, la méthode « on t’envoie un lien par e-mail à chaque connexion » semble être l’authentification sans mot de passe la plus conviviale
L’habitude de mettre des passkeys dans 1Password ne me rassure pas complètement non plus. Je sais que cela m’y lie pour toujours. Mais j’aime le service, et si je veux en partir un jour, j’aurai au moins la liste des comptes à recréer
Ce qui me fait le plus peur, c’est d’oublier le code de mon téléphone. Une fois, je me suis réveillé et, à un très mauvais moment, j’ai été distrait au point de ne plus du tout me souvenir du code à 6 chiffres. J’utilise le même code pour déverrouiller mon poste de travail. Après avoir pensé à autre chose un instant, j’ai fini par le retrouver grâce à la mémoire musculaire
C’était vraiment un moment du genre « est-ce que je viens de faire un AVC ? ». Maintenant, j’ai enregistré ce code dans 1Password, donc si j’ai au moins un appareil déverrouillé, je peux me rafraîchir la mémoire. C’était il y a assez longtemps, je ne pense pas que ce soit de la démence ; juste un phénomène temporaire étrange
En revanche, je me souviens parfaitement de tous les mots de passe professionnels d’une durée de vie maximale d’un an que j’ai utilisés. Mais ce n’est pas très utile si je n’arrive pas à me rappeler un code à 6 chiffres
Donc les mots de passe vont sans doute bientôt rejoindre « Killed by Google », et mon compte avec. Je ne garde aucun appareil connecté
Il est largement temps de déplacer les quelques usages qu’il me reste. Je me demande si, le jour où l’inévitable arrivera, mon entreprise pourra réinitialiser la passkey de mon compte professionnel
Je pense que c’est la bonne direction, mais j’ai vu trop d’histoires terrifiantes de personnes bloquées hors de leur compte Google ou iCloud, sans véritable moyen de le récupérer
Je ne pense pas être le seul à avoir cette impression, mais un jour, probablement à cause d’une erreur de ma part, je vais me retrouver bloqué chez Google et ma vie numérique sera fichue
Je serais prêt à payer pour qu’une entreprise privée propose un système de connexion façon login.gov, avec la possibilité de parler à une vraie personne, comme à l’USPS, en cas de blocage
https://mastodon.laurenweinstein.org/@lauren/111103819626952...
https://mastodon.laurenweinstein.org/@lauren/111211366080459...
Ce n’est pas une question de si, mais de quand. Pour toute personne qui accorde de l’importance à ses données, des sauvegardes et un plan rigoureux de reprise après sinistre sont indispensables. Une entreprise finira par casser quelque chose, même sans faute de votre part, et c’est inévitable
Malheureusement, pour certains aspects d’un compte perdu, il n’existe pas de bonnes options de reprise après sinistre, mais avoir plusieurs comptes et éviter les points de défaillance uniques aide dans une certaine mesure
Il faut disposer de plusieurs moyens indépendants de se connecter. Par exemple, imprimer des codes de secours et les conserver avec des documents importants
Mais cela ne protège pas non plus contre un blocage de compte dû à un changement de politique de Google ; idéalement, il faudrait donc aussi s’entraîner à tenir sans compte Google
Lauren Weinstein avertit que Passkey est défectueux et va devenir un énorme casse-tête, en particulier pour les utilisateurs ordinaires
https://mastodon.laurenweinstein.org/@lauren/111103819626952...
https://mastodon.laurenweinstein.org/@lauren/111211366080459...
Si l’on met de côté, pour l’instant, les questions de confidentialité et d’enfermement fournisseur, Passkey n’est pas une si mauvaise alternative pour les personnes qui réutilisent le même mot de passe principal sur tous les sites, sans authentification à deux facteurs
Mais dès qu’on commence à compter dessus pour protéger réellement quelque chose, cela devient vite un énorme cauchemar. Et c’est encore pire parce qu’on le traite comme équivalent à mot de passe + authentification à deux facteurs
Il dit que c’est « facile à trouver », mais je n’ai justement pas l’impression de le trouver
https://mastodon.laurenweinstein.org/@lauren/111211489395997...
Si l’utilisateur a de toute façon de fortes chances d’utiliser un mot de passe faible pour le service, je ne vois pas pourquoi un code d’appareil faible serait une raison d’éviter Passkey
Dans ce cas, si l’authentification de l’appareil est compromise, le compte l’est de toute façon aussi
En particulier, chez Google, le système actuel ne force pas à choisir uniquement entre mot de passe et Passkey. Si l’appareil n’a pas de Passkey, on peut revenir au flux de connexion par mot de passe
Pour comparer les risques et les bénéfices, il faudrait savoir à quel point les gens réutilisent réellement leurs mots de passe, s’ils utilisent l’authentification à deux facteurs, s’ils font dépendre tout l’accès à leurs comptes uniquement du verrouillage de l’écran de leur téléphone, s’ils utilisent la biométrie, à quelle fréquence la récupération de compte est nécessaire, etc.
Seules ces données pourraient clarifier le débat, et permettre aussi à chacun d’aboutir à une conclusion différente selon sa propre situation
Google possède la plupart de ces données. Pour étayer sa position, il devrait les publier
1Password a récemment activé la prise en charge des passkeys, et j’ai été « surpris » de découvrir qu’il n’existe aucun moyen de les exporter hors de 1Password
Elles ne sont incluses ni dans l’export au format 1PUX, ni dans le CSV
Autrement dit, il est littéralement impossible de les sauvegarder. Si 1Password tombe en panne, si l’entreprise met la clé sous la porte, ou si quelque chose de similaire arrive, les passkeys disparaissent tout simplement. Il n’existe aucun moyen de les récupérer
Voir ce récent AMA de 1Password sur les passkeys à ce sujet :
https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
Pour ce qui est d’un éventuel arrêt de 1Password, les mots de passe comme les passkeys sont aussi stockés localement lorsqu’ils sont synchronisés sur les appareils. Même si, pour une raison quelconque, vous perdez l’accès à 1Password, vous pouvez continuer à accéder à tous les éléments du coffre ; vous ne perdez que la synchronisation entre appareils
Plutôt que de déplacer des passkeys entre appareils, il faut voir le modèle comme celui des clés SSH : on génère une passkey différente par appareil et on les enregistre toutes auprès du service concerné
Bien sûr, un utilisateur peut toujours être trompé et ajouter la passkey d’un attaquant à son compte
Sur mobile, ce problème a été réglé il y a des années, mais l’e-mail reste encore un bazar. La leçon, c’est de ne jamais se laisser enfermer
Il intercepte les appels à
window.credentials, et si vous voulez utiliser 1Password en parallèle d’un autre moyen de vérification comme une Yubikey, vous devez aller dans les paramètres et désactiver entièrement la fonctionnalité passkeyC’est aussi assez similaire à la manière dont il intercepte les invites Google One Tap et les désactive globalement pour afficher sa propre invite OAuth. Je n’utilise que l’extension Chrome, donc je ne sais pas si l’expérience avec l’application native est très différente
Du point de vue utilisateur, je ne comprends toujours pas
Si ma maison brûle, ou qu’un autre événement détruit tous les appareils sur lesquels j’étais connecté à Google, que se passe-t-il ? Comment me reconnecter à mon compte ?
Je lui ai donné un ancien téléphone et le transfert de la SIM s’est bien passé, mais impossible de se connecter au compte Google. Google insistait sans cesse en disant « utilisez votre téléphone ». Le portable était également déconnecté de l’e-mail
Heureusement, à cause d’un incident précédent, j’avais des jetons de secours, ce qui a permis de résoudre le problème. Je ne sais pas comment les autres s’en sortent
On divise la clé en M fragments, et il en faut N pour la reconstituer. Par exemple, en 3/8, il suffit de 3 fragments sur 8 pour récupérer la clé. On confie chaque fragment à des personnes de confiance, puis, lors de la récupération, on récupère des fragments auprès d’au moins 3 d’entre elles afin de reconstruire la clé
Quand je l’ai implémenté dans une démo YC appelée multipasskey, l’utilisateur choisissait des contacts de confiance, et les fragments de clé leur étaient envoyés en arrière-plan. En cas de besoin de récupération, on leur envoyait une demande, et une fois suffisamment de fragments reçus, la clé de l’appareil était reconstituée. Une fois cette clé disponible, une sauvegarde chiffrée des clés était téléchargée depuis un serveur distant, ce qui permettait de restaurer le tout comme neuf
En 2017/2018, j’ai candidaté à YC avec ce projet, que j’appelais multipasskey, sous forme de démo fonctionnelle, mais j’ai été refusé. J’imagine que je n’ai pas su l’expliquer
En tant que technicien, je suppose que cela signifie qu’il faut confier un appareil de secours à un ami, ou stocker aussi les passkeys dans un compte Apple/Microsoft/gestionnaire de mots de passe
Mais Google devrait l’expliquer plus en détail
Et il ne faut absolument jamais perdre son numéro de téléphone. Même avec le nom d’utilisateur, le mot de passe et l’e-mail de récupération, impossible de récupérer l’accès à un compte Google si l’on ne peut pas recevoir le code SMS
Pendant cette période de transition, il est recommandé de proposer les passkeys comme alternative aux moyens déjà existants. C’est ce que font Google et de nombreux fournisseurs de services
Cela dit, la question que tu soulèves relève de la récupération de compte, et tout le monde devrait se la poser même sans passkeys. Il faut avoir prévu comment se connecter si l’on oublie son mot de passe, si l’on perd l’accès à son gestionnaire de mots de passe, ou si l’on perd son second appareil d’authentification. L’arrivée des passkeys ne supprime pas complètement la nécessité de réfléchir à la récupération de compte
Il existe tout de même des cas particuliers où les passkeys améliorent la récupération de compte. Si vous créez une passkey pour votre compte Google depuis un appareil Apple utilisant iCloud Keychain, cette passkey est synchronisée dans iCloud. Ainsi, même si votre maison brûle et que vous perdez tous vos appareils, tant que vous pouvez accéder à votre compte iCloud, vous pouvez récupérer les passkeys de votre compte Google et d’autres sites web
Bien sûr, la question « et si je perds l’accès à mon compte Apple iCloud ? » est légitime. Le problème de la récupération de compte ne disparaît donc pas complètement, mais dans de nombreux cas, les passkeys peuvent le réduire considérablement
Il y a ici le paradoxe de Simpson
En moyenne, cela peut améliorer la sécurité. Parce que la grande majorité des utilisateurs utilisent les mots de passe de façon vraiment catastrophique
Mais pour les utilisateurs expérimentés qui utilisent les mots de passe de manière sûre, si on les y force, la sécurité chute brutalement
L’authentification à deux facteurs par numéro de téléphone obligatoire a le même effet. Dans le cas de Big G, l’authentification à deux facteurs par numéro de téléphone obligatoire est une politique anti-anonymat déguisée en sécurité. Dans le cas présent, cela ressemble à une tentative de récupérer des données biométriques
Pour la plupart des gens, le numéro de téléphone est le meilleur identifiant durable dont ils disposent, et Google doit assurer la récupération de compte pour des milliards d’utilisateurs à une échelle absurde
Beaucoup de gens perdent leurs mots de passe et leurs appareils, mais très peu perdent leur numéro de téléphone
Il est donc logique que Google utilise les numéros de téléphone pour attribuer et déléguer l’identité sur sa plateforme. C’est mauvais pour la vie privée, mais très bon pour la sécurité, car cela permet de contrôler les données via un « justificatif » d’authentification tiers que l’utilisateur n’a pas à gérer lui-même
Et je ne suis pas sûr de cette partie, donc que quelqu’un qui sait me corrige. Même en supposant un utilisateur expérimenté immunisé contre les mots de passe faibles, la réutilisation et le phishing, je comprends qu’il y a un avantage de sécurité. Même si une Passkey Google fuit, seule la clé publique fuit, et comme on ne peut pas se connecter avec la clé publique, la fuite devient quasiment inutile
Si Google collectait des données biométriques, il l’aurait déjà fait, et ce serait sans rapport avec cette fonctionnalité
Les détails très élémentaires de ce modèle de sécurité sont vrais depuis longtemps, depuis l’époque où l’iPhone a commencé à utiliser la Secure Enclave. Je ne comprends pas pourquoi les gens sur ce site parlent avec autant d’assurance de choses qu’ils ne comprennent absolument pas, et honnêtement cela m’étonne
Une Passkey est moralement équivalente à l’utilisation d’une clé SSH au lieu d’un mot de passe SSH pour se connecter à un serveur, appliquée aux sites web. De plus, il existe aussi un fait simple et objectif que l’idée de « bien utiliser ses mots de passe » ne peut pas remplacer : les Passkeys sont littéralement résistantes au phishing
Je suis surpris qu’ils poussent déjà ça. Pas plus tard que la semaine dernière, il restait assez d’aspérités dans l’implémentation pour que je le désactive dans mon tenant Workspace
Les deux choses les plus agaçantes sont que l’Advanced Protection ne prend pas encore en charge les Passkeys, donc il faut conserver U2F pour le moment, et que si une clé U2F est configurée sur le compte, Google invite d’abord à l’utiliser comme Passkey, puis, comme ce n’est pas une Passkey, demande de se connecter avec le mot de passe
Résultat : les personnes qui utilisent une authentification multifacteur résistante au phishing perdent la fonction qui permet à l’appareil de « mémoriser » l’étape d’authentification multifacteur. Parce que Google exige toujours le facteur U2F avant le mot de passe
À part ça, en préparant le déploiement d’une connexion sans mot de passe basée sur Okta chez quelques petits clients, j’ai beaucoup testé les flux FIDO2 avec clés de sécurité et Passkeys sur différents types d’appareils et plateformes. Le flux d’authentification lui-même me plaît globalement, mais il y a beaucoup de pièges auxquels faire attention
J’ai passé pas mal de temps à nettoyer le chemin nominal, à créer des supports d’onboarding et à documenter les scénarios de continuité d’activité. Les cas d’usage personnels sont plus difficiles à certains égards, car il faut penser à chaque service plutôt qu’à un IdP unique
Si vous devez prendre en charge plusieurs environnements, la voie la plus simple aujourd’hui consiste à investir dans 1Password ou dans un autre gestionnaire de mots de passe prenant en charge les Passkeys. Cela offre l’expérience utilisateur la plus cohérente et fonctionne sur la plupart des plateformes, mais il y a encore des problèmes avec Android 14
Pour les comptes à privilèges élevés, je continuerai à utiliser des clés matérielles, donc les administrateurs reçoivent une paire de clés FIDO2. Les autres reçoivent une Yubikey, qui sert de sauvegarde s’ils perdent l’accès à leur appareil ou doivent se connecter depuis un appareil non fiable. Android pose aussi problème ici. Même avec la version 14, il ne semble pas prendre en charge les flux FIDO2 sans mot de passe
C’est une direction intéressante. Cela dit, il vaut la peine de rappeler que les données biométriques comme les empreintes digitales ou la reconnaissance faciale ne sont pas vraiment des « secrets »
Elles peuvent être observées ou exploitées à l’insu de l’utilisateur ou sans son consentement, et à bien des égards elles se comportent davantage comme un nom d’utilisateur que comme un mot de passe
L’empreinte ne fait que déverrouiller la paire de clés cryptographiques qui sera utilisée pour l’authentification
J’utilise une Yubico Security Key comme Passkey, protégée par un PIN à 6 chiffres. Ce PIN n’existe que localement sur l’appareil et sert à empêcher quelqu’un qui possède physiquement l’appareil de se connecter immédiatement. Si le PIN est saisi de façon incorrecte 10 fois de suite, la clé est effacée
Quand on saisit le PIN, la clé est déverrouillée, et c’est bien cette clé qui permet d’accéder au compte Google
La plupart des comptes avec mot de passe disposent d’un filet de sécurité du type « si vous prouvez votre identité à l’entreprise, elle le réinitialisera ». Par exemple, si vous ne vous souvenez plus de votre mot de passe bancaire, la banque a un moyen de le réinitialiser
Pour ce que contrôle Google, il n’existe absolument aucun moyen de les contacter pour résoudre un problème. C’est déjà un problème dans tous les produits Google
Enfermer tous les accès derrière une porte contrôlée par Google, c’est se préparer soi-même un cauchemar futur
Dommage qu’on ne puisse pas encore stocker de Passkeys dans Bitwarden. Cela dit, d’après le message en haut de cette page, cela devrait arriver en octobre
https://bitwarden.com/blog/bitwarden-passkey-management/