Les passkeys, et ce qui se déplace

Éditorial

Les passkeys suppriment l'hameçonnage par construction, grâce à la liaison de chaque clé à une origine. Elles ne suppriment pas le risque : elles le déplacent vers la synchronisation, la récupération du compte de plateforme et la dépendance à un écosystème, et c'est là qu'il faut désormais regarder.

Mis à jour le 25 septembre 2026~27 min de lecture12 sections

papy cyber

→ Lire l’explication complète de la marmotte

Une bonne nouvelle, pour une fois

Il faut le dire d’emblée, avec la gravité qui sied aux événements rares : une technologie grand public vient de régler un problème de sécurité. Pas de le « mitiger », de le « réduire », d’en « abaisser la probabilité résiduelle » selon la liturgie en vigueur dans les comités de pilotage. De le régler. Le vieil homme qui écrit ces lignes a vu passer assez de révolutions définitives pour savoir que la plupart ne survivent pas à leur deuxième salon professionnel. Celle-ci, fait remarquable, fonctionne.

L’hameçonnage d’identifiants repose sur une méprise que l’humanité commet depuis qu’elle a inventé la porte : on croit parler au propriétaire, on parle à quelqu’un qui a imprimé le même logo. Le mot de passe est un secret portable, qui vaut partout où on le récite. Le code à usage unique aussi, pendant trente secondes, ce qui laisse à un intermédiaire le temps de le relayer et de prendre un café. La notification poussée est une approbation portable, que l’utilisateur finit par accorder comme on signe un bon de livraison, pour que le livreur s’en aille. Tout ce qui peut être saisi, lu ou validé par un humain peut être relayé par un autre humain, moins bien intentionné. Les passkeys retirent à l’utilisateur la question « à qui suis-je en train de parler ? » et la confient au navigateur. C’est humiliant pour l’espèce, et c’est très efficace.

Voilà pour la bonne nouvelle. La suite sera moins aimable, et je préfère prévenir qu’on n’y trouvera pas de réquisitoire : seulement la constatation, banale en physique et scandaleuse en marketing, que rien ne disparaît, tout se déplace. La passkey ne supprime pas le risque d’accès illégitime. Elle le chasse du moment de la connexion, où on savait le voir, vers des pièces moins éclairées : le compte qui synchronise les clés, la procédure qui permet de récupérer ce compte, le téléphone qui les déverrouille, l’écosystème dont on ne sort plus. Ces pièces existaient déjà. Ce qui est nouveau, c’est qu’on y a rangé toute l’argenterie.

La question de cet éditorial n’est donc pas « faut-il adopter les passkeys ? ». Oui. Dans l’immense majorité des cas, oui, et je le dis maintenant pour épargner au lecteur pressé la lecture de la conclusion. La question est : une fois l’hameçonnage réglé, où est passée la surface d’attaque, et qui la surveille ? La réponse courte est « ailleurs » et « personne ». La réponse longue suit.

Ce que règle la liaison à l’origine

Le mécanisme mérite d’être posé exactement, parce que tout le reste en découle et qu’on ne raille bien que ce qu’on a compris.

Une passkey est un identifiant WebAuthn : une paire de clés asymétriques créée par un authentificateur (la puce sécurisée d’un téléphone, le module de sécurité d’un ordinateur, une clé matérielle, ou un gestionnaire logiciel) pour un seul service. Le service ne reçoit que la clé publique. La clé privée reste dans l’authentificateur, ou dans le coffre qui le synchronise ; retenez cette incise, elle est le sujet de l’éditorial sous un déguisement de parenthèse.

À l’enrôlement, la paire est rattachée à un identifiant de partie utilisatrice (le relying party ID), qui est un nom de domaine. À chaque connexion, le serveur envoie un défi aléatoire ; le navigateur construit une structure qui contient ce défi et l’origine réelle de la page qui fait la demande ; l’authentificateur signe l’ensemble. Le serveur vérifie la signature, le défi, l’origine. Le code d’enregistrement côté navigateur figure dans la page Authentifier les personnes et les services ; je ne le recopie pas, l’âge m’a appris l’économie.

Deux verrous se superposent.

Le premier est dans le navigateur. Une page servie depuis un domaine trompeur ne peut pas demander une signature pour le domaine légitime : l’identifiant de partie utilisatrice doit correspondre au domaine de la page, ou à un domaine parent qu’elle est autorisée à revendiquer. L’utilisateur ne voit même pas sa passkey proposée. Il n’a pas de décision à prendre, donc pas de décision à rater, ce qui est la définition la plus honnête de l’ergonomie de sécurité.

Le second est dans le serveur. Même si un intermédiaire obtenait une signature, elle porterait l’origine de la page qui l’a demandée, et le serveur légitime la rejetterait. Le relais en temps réel, qui fait son miel des codes à usage unique, se heurte à un objet signé qui dit exactement où il est né. On ne falsifie pas un acte de naissance cryptographique en changeant la couleur du bouton.

Ce double verrou a une conséquence qu’on n’ose pas formuler en réunion : il fonctionne indépendamment de la vigilance de l’utilisateur. Des décennies de sensibilisation (survolez les liens, méfiez-vous de l’urgence, vérifiez l’adresse, et surtout ne cliquez sur rien, jamais, nulle part) deviennent, pour la connexion elle-même, superflues. On cesse de demander à un comptable fatigué de faire le travail d’un comparateur de chaînes de caractères. Les formateurs en sensibilisation garderont du travail, rassurons-les : il reste tout le reste.

S’y ajoute un bénéfice plus discret. Le serveur ne détient plus de secret. Une base de clés publiques volée ne permet de se connecter nulle part, et le bourrage d’identifiants (rejouer sur un site les mots de passe fuités d’un autre) perd son carburant. La réutilisation, péché capital du mot de passe et vertu cardinale de l’utilisateur pressé, n’a plus de sens : chaque paire est propre à un service, par construction. L’humanité est privée d’un de ses vices, sans même avoir eu à s’en repentir.

Ce que la liaison à l’origine ne couvre pas

Soyons aussi précis sur les limites que sur les forces, puisque les plaquettes commerciales ne le seront pas. La liaison à l’origine protège l’acte de connexion. Elle ne protège pas :

la session qui en résulte. Une fois authentifié, le navigateur reçoit un cookie ou un jeton. Un logiciel malveillant qui vole ce cookie obtient une session valide sans avoir jamais approché la passkey. On a blindé la porte ; le cambrioleur attend désormais qu’on l’ouvre et entre derrière vous. Le vol de session est précisément l’endroit où les attaquants se sont reportés quand l’authentification s’est durcie, avec la souplesse d’adaptation qui manque tant aux organigrammes ;
l’appareil compromis. Un poste contrôlé par l’attaquant peut solliciter l’authentificateur à des moments choisis, ou attendre que l’utilisateur le fasse. La vérification de présence et la vérification de l’utilisateur limitent l’usage furtif ; elles n’empêchent pas un poste compromis d’agir pendant une session légitime ;
les parcours hors passkey. Si le service conserve un mot de passe en repli, ou un lien de connexion par courriel, l’attaquant hameçonne le repli. Une porte blindée à côté d’une porte en carton ne fait pas une maison blindée ; elle fait une porte en carton avec un voisin impressionnant ;
l’enrôlement. Si un attaquant parvient à enregistrer sa propre passkey sur le compte de la victime, à la faveur d’une session volée ou d’une récupération complaisante, la liaison à l’origine le protège désormais, lui, avec la même rigueur impartiale.

Ce dernier point est le pivot de tout ce qui suit. La passkey est un excellent verrou. La question devient : qui a le droit de poser un nouveau verrou, et qui a un double des clés ?

Synchronisées ou liées à un appareil : deux objets sous un même mot

Le mot « passkey » désigne aujourd’hui deux objets dont le modèle de menace diffère profondément. Le vocabulaire courant les confond avec une constance qu’on aimerait voir appliquée à la rotation des secrets.

La passkey liée à un appareil (device-bound) naît dans un authentificateur et n’en sort jamais. La clé privée est générée dans un composant qui ne sait pas l’exporter. Perdre l’objet, c’est perdre la clé. Le voler, c’est posséder la clé, tant qu’on l’a en main et qu’on connaît le code qui la déverrouille. Elle a les propriétés rassurantes et exaspérantes d’un objet physique : elle n’existe qu’à un endroit à la fois, et cet endroit est rarement celui où on la cherche.

La passkey synchronisée naît dans un authentificateur puis est copiée, par le fournisseur de plateforme ou par un gestionnaire tiers, vers les autres appareils du même compte. La clé privée existe donc, chiffrée, dans une infrastructure de synchronisation, et en clair au moment de l’usage sur chacun des appareils rattachés. Perdre son téléphone n’est plus un drame : la clé est ailleurs. C’est ce qui a rendu l’adoption possible. C’est aussi ce qui change tout.

La différence n’est pas de degré mais de nature. Dans le premier cas, la sécurité de l’accès égale la sécurité d’un objet. Dans le second, elle égale la sécurité d’un compte : celui qui synchronise. Et un compte, contrairement à un objet, possède cette institution merveilleuse et redoutable qu’on appelle la procédure de récupération. Un porte-clés perdu ne se récupère pas en appelant un numéro vert. Un compte, si.

Le protocole n’ignore pas la distinction, lui. Les données de l’authentificateur transmises au serveur comportent des indicateurs qui disent si un identifiant est éligible à la sauvegarde et s’il est effectivement sauvegardé. Un service peut donc savoir à quelle catégorie appartient la passkey qu’on lui présente, et exiger une clé liée à un appareil pour les opérations sensibles. En pratique, très peu de services exploitent cette information, et la plupart des utilisateurs ignorent laquelle des deux ils ont créée, l’interface ayant jugé plus élégant de ne pas les inquiéter.

L’attestation, espèce en voie de raréfaction

Un service qui veut savoir quel authentificateur a créé une clé peut demander une attestation : une déclaration signée par le fabricant qui identifie le modèle. C’est ce qui permet, dans un contexte exigeant, de n’accepter que des clés matérielles d’une liste approuvée. La logique est celle qui rattache une clé à une identité certifiée par un tiers, que la page Relier une clé à une identité décrit pour les certificats, appliquée ici au matériel plutôt qu’à la personne.

Les passkeys synchronisées rendent l’exercice largement vain. Une clé destinée à vivre sur plusieurs appareils, de plusieurs modèles, ne peut pas être attestée comme issue d’un composant précis ; et les fournisseurs grand public, pour des raisons de vie privée autant que de cohérence, tendent à ne pas fournir d’attestation exploitable. Conséquence sans détour : un service qui a besoin de garanties sur l’authentificateur ne peut pas les obtenir d’une passkey synchronisée. Il doit exiger une clé liée à un appareil, avec attestation, et accepter de gérer des petits objets en plastique que les gens perdent dans des vestes qu’ils ne mettent plus.

Où va la clé quand elle se synchronise

Suivons la clé privée d’une passkey synchronisée, comme on suit un héritier dans un roman du XIXᵉ siècle : c’est elle qui a la fortune, et tout le monde lui veut du bien.

Elle naît sur un appareil. Elle est chiffrée, puis envoyée vers l’infrastructure du fournisseur. Les grands fournisseurs annoncent un chiffrement de bout en bout : les clés du coffre sont dérivées de secrets que seuls les appareils de l’utilisateur détiennent (typiquement, le code de verrouillage d’un appareil déjà enrôlé), si bien que le fournisseur stocke des blocs qu’il ne peut pas lire. Je n’ai aucune raison de mettre ces affirmations en doute dans leur principe. Je n’ai pas davantage les moyens de les vérifier dans leur mise en œuvre, et personne à l’extérieur de ces organisations ne les a vraiment. Premier déplacement, donc : la confiance dans un algorithme public est remplacée par la confiance dans une architecture propriétaire décrite par son propriétaire. C’est une forme de foi. Elle a ses fidèles, ses textes sacrés en format livre blanc, et, comme toute foi, elle n’admet pas l’inspection des reliques.

Ensuite, la clé arrive sur un nouvel appareil. Celui-ci obtient le droit de déchiffrer le coffre en prouvant qu’il appartient au même compte et en présentant un secret d’un appareil déjà connu. Deuxième déplacement, le plus important : l’événement critique n’est plus la connexion à un service, c’est l’ajout d’un appareil au compte de plateforme. Celui qui réussit à ajouter un appareil hérite, en une opération, de toutes les passkeys de tous les services. Le testament est universel et le notaire est un formulaire.

Le troisième déplacement concerne le déverrouillage local. Sur chaque appareil, la passkey est protégée par la vérification de l’utilisateur, qui est le plus souvent le déverrouillage de l’appareil lui-même : biométrie, ou code de repli. Le code de verrouillage du téléphone devient ainsi un facteur d’authentification pour tous les services. Le même code à quatre chiffres qu’on tape dans le métro sous le regard distrait de quarante inconnus. Un code observé par-dessus l’épaule, puis le vol du téléphone, n’ouvrent pas seulement le téléphone : selon la conception de la plateforme, ils peuvent ouvrir le coffre, puis tout ce qu’il contient. Ce scénario ne suppose aucune faiblesse cryptographique, seulement qu’on ait confondu un code d’écran avec une clé maîtresse, ce que l’être humain fait avec une régularité qui force l’admiration.

Enfin, les gestionnaires tiers ajoutent une couche. Un gestionnaire de mots de passe qui stocke aussi des passkeys devient le coffre ; son propre déverrouillage (mot de passe maître, biométrie, déverrouillage par l’appareil) devient la porte. La solidité de cette porte dépend de la conception du gestionnaire et de la dérivation de clé qui la protège, ce que la page Transformer mots de passe et secrets applicatifs en clés détaille. On notera la saveur de la situation : le dispositif conçu pour se débarrasser des mots de passe repose, en dernier ressort, sur un mot de passe. L’objet à protéger est le coffre, et la passkey n’en est qu’un locataire.

Le compte de plateforme, nouveau maître des clés

Tirons le fil jusqu’au bout. Une organisation qui adopte massivement les passkeys synchronisées opère une concentration : des dizaines de secrets indépendants, chacun médiocre à sa façon, sont remplacés par des dizaines de clés excellentes, toutes gardées par un seul compte. La surface d’attaque se réduit en nombre et augmente en valeur unitaire. C’est généralement une bonne affaire, parce que ce compte unique est aussi celui qu’on peut le mieux protéger. Mais c’est une affaire qu’on signe, et il est d’usage de lire un contrat avant de le signer, même si l’usage se perd.

Ce compte a trois propriétés qui le rendent singulier.

Il est souvent personnel. Dans une petite structure, le compte de plateforme qui synchronise les passkeys professionnelles est fréquemment celui du salarié, lié à son téléphone, à sa carte bancaire et aux photos de son chat. L’organisation n’a aucune autorité dessus. Elle ne peut ni imposer sa politique de récupération, ni le suspendre au départ de la personne, ni savoir sur combien d’appareils ses clés professionnelles existent. Supposons une PME de vingt postes qui migre ses accès vers des passkeys sans poser la question : elle aura amélioré la résistance à l’hameçonnage de chacun de ses comptes, et confié la garde de l’ensemble à vingt comptes grand public dont elle ignore tout, y compris le nom du chat. Le progrès est réel. Le pouvoir, lui, a déménagé sans laisser d’adresse.

Il est récupérable par une procédure qui n’a pas été conçue pour vous. Le fournisseur de plateforme sert une humanité qui oublie ses codes, noie ses téléphones et change de numéro comme de chemise. Sa procédure de récupération est un compromis entre sécurité et taux d’abandon, calibré pour la population générale. Il est raisonnable de penser qu’elle est bien faite ; il est naïf de croire qu’elle a été calibrée pour protéger la comptabilité d’une entreprise. L’éditorial La récupération de compte, maillon faible développe ce point pour lui-même, car il le mérite et parce que je n’ai pas fini d’en dire du mal.

Il est hors du champ de vos journaux. Quand un nouvel appareil est ajouté au compte de plateforme d’un salarié, l’organisation n’en voit rien. Aucune alerte dans son outil de supervision, aucune trace dans ses journaux d’authentification, puisque, du point de vue de chaque service, la connexion suivante sera parfaitement légitime : bonne clé, bonne origine, bonne signature. Une compromission du coffre produit des connexions indiscernables des connexions normales. C’est la rançon de la perfection cryptographique : une preuve impeccable l’est pour tout le monde, y compris pour celui qui l’a volée. La mathématique n’a pas de morale ; c’est même ce qu’on lui demande.

Le remède n’est pas de refuser la synchronisation, mais de la placer sous un compte qu’on gouverne. Les plateformes proposent, pour les parcs gérés, des comptes professionnels administrés, avec des politiques de récupération et de révocation contrôlées par l’organisation. Les gestionnaires tiers proposent des coffres d’entreprise. L’un ou l’autre ramène le maître des clés dans le périmètre. Ce qui ne marche pas, c’est de laisser la question sans réponse, parce qu’une question sans réponse en sécurité n’est jamais longtemps sans réponse : quelqu’un finit toujours par la donner, et ce n’est pas vous.

Le verrou d’écosystème

Le troisième déplacement est moins technique et plus durable. Il concerne la sortie, dont on sait depuis les grands écrivains de l’absurde qu’elle est l’endroit le plus mal indiqué de tout bâtiment.

Un mot de passe est un objet transportable. On peut le noter, l’exporter, le copier d’un gestionnaire à l’autre ; c’est d’ailleurs un de ses défauts, et il en tirait une liberté que nul ne lui enviait. Une passkey synchronisée, elle, vit dans le coffre d’un fournisseur, sous un format et un chiffrement propres à ce fournisseur. Pendant les premières années du déploiement, il n’existait pas de moyen standard de la faire passer d’un écosystème à un autre. Changer de plateforme revenait à recréer, service par service, de nouvelles passkeys, en se connectant d’abord à chacun par un autre moyen, c’est-à-dire, le plus souvent, par le mot de passe qu’on venait de supprimer.

Des travaux de standardisation portent sur un format et un protocole d’échange d’identifiants entre fournisseurs, et certains gestionnaires ont commencé à les mettre en œuvre. C’est bienvenu, et c’est exactement le genre de sujet dont l’état change d’un trimestre à l’autre : je ne m’avancerai pas sur sa maturité à la date où vous lisez, et je vous renvoie à la documentation de l’alliance FIDO et de votre fournisseur. Même dans l’hypothèse la plus favorable, l’échange suppose que les deux fournisseurs le prennent en charge et que l’utilisateur pense à s’en servir avant de perdre l’accès à l’ancien coffre. La prévoyance étant la vertu la moins répandue après la modestie, on peut douter.

La dépendance a plusieurs visages :

technique : les passkeys fonctionnent pleinement sur les appareils du fournisseur, et par des chemins détournés ailleurs. Le parcours « hybride » (scanner un code QR avec son téléphone pour se connecter sur un ordinateur tiers, avec une vérification de proximité par Bluetooth) comble une partie de l’écart, au prix d’une ergonomie qui semble avoir été testée sur des volontaires particulièrement patients ;
contractuelle : la suspension du compte de plateforme, pour une raison quelconque (litige de paiement, soupçon de fraude, erreur d’un automate que personne ne peut joindre), suspend l’accès à tous les services dont les passkeys y vivent. Le fournisseur devient, sans l’avoir demandé, le point de défaillance unique de votre identité numérique. Il n’en tire aucune joie ; vous non plus ;
organisationnelle : une organisation qui a bâti sa politique d’authentification sur les fonctions d’un fournisseur ne choisit plus librement ses postes et ses téléphones. Elle croit avoir choisi une technologie ; elle a choisi un fournisseur, et c’est lui qui choisira la suite.

Aucune de ces dépendances n’est scandaleuse. Nous vivons déjà avec des dépendances comparables pour le courrier, le stockage, la bureautique, et nous y survivons avec la résignation paisible des locataires. Mais il y a une asymétrie : l’identité est la dépendance dont on sort le plus difficilement, parce que pour la quitter, il faut déjà pouvoir s’authentifier ailleurs. C’est la seule prison dont la clé est aussi le formulaire de sortie.

Le meilleur argument contre cet éditorial

Il serait malhonnête de conclure sans donner la parole à la défense, et de la lui donner dans sa version la plus forte. La voici, sans ironie, ou presque : elle a le mauvais goût d’être solide.

Le déplacement décrit ici est un progrès net, pas un transfert à somme nulle. Avant les passkeys, la surface d’attaque était à la fois la connexion (hameçonnage, relais, bourrage d’identifiants) et la récupération (courriel, SMS, support) et l’appareil (logiciels malveillants, vol de session). Les passkeys retirent le premier terme sans en ajouter de nouveau : le compte de plateforme existait déjà, il était déjà le pivot de la récupération de la plupart des comptes en ligne, puisque c’est lui qui recevait les courriels de réinitialisation. Dire que les passkeys « déplacent » le risque vers ce compte, c’est découvrir l’Amérique en 2026.

Ensuite, le compte de plateforme est le mieux défendu de tous. Les grands fournisseurs y consacrent des moyens de détection, d’analyse comportementale et de protection de la récupération sans commune mesure avec ce que peut faire un site marchand ou une PME. Concentrer la sécurité sur ce compte, c’est la confier à ceux qui savent la faire.

Enfin, la perfection est l’ennemie de l’adoption. Les clés liées à un appareil existent depuis longtemps ; elles ne sont jamais sorties d’un public averti, précisément parce que leur perte est un drame. La synchronisation est ce qui a fait sortir l’authentification forte de la niche. Exiger mieux, c’est en pratique conserver le mot de passe pour la majorité, et donc tout perdre au nom de l’excellence.

Je souscris à presque tout cela, ce qui est pénible pour un auteur qui s’était promis de ronchonner. Pour la population générale, la passkey synchronisée est une amélioration massive et sans ambiguïté, et un éditorial qui laisserait croire le contraire serait nuisible. Mon désaccord porte sur un seul point : l’argument vaut pour l’individu face aux attaques de masse, il vaut moins pour une organisation face à une attaque ciblée. L’attaquant opportuniste qui achète des listes d’identifiants au kilo est éliminé, et on ne le pleurera pas. L’attaquant qui vise cette comptable ou cet administrateur, lui, lit les mêmes documentations que nous, souvent plus attentivement. Pour lui, le déplacement n’est pas un détail : c’est la carte du nouveau terrain, et on vient de la lui imprimer en couleur.

Ce que je ferais, concrètement

Ce qui suit n’est pas une norme ; ce sont les conséquences du raisonnement, formulées pour être discutées plutôt que révérées.

Classer les comptes avant de choisir l’authentificateur. Tous les accès n’appellent pas la même réponse. Pour les comptes ordinaires, une passkey synchronisée est un excellent choix. Pour ceux qui ouvrent l’administration du système d’information, la gestion des identités elle-même, la finance ou les sauvegardes, je préconiserais des passkeys liées à un appareil, sur clé matérielle, en deux exemplaires enrôlés dont un conservé à part, ailleurs que dans le tiroir du premier. La rubrique Identités, accès et habilitations situe cette distinction dans l’ensemble plus large des privilèges.

Mettre le coffre sous gouvernance. Pour un usage professionnel, les passkeys doivent vivre dans un coffre dont l’organisation contrôle la récupération et la révocation. La question « où sont les clés de nos accès, et qui peut ajouter un appareil à ce coffre ? » doit avoir une réponse écrite, datée, et relue par quelqu’un d’autre que son auteur.

Fermer les portes latérales. Un compte doté d’une passkey et d’un mot de passe de repli est un compte à mot de passe qui a mis une cravate. Pour les comptes sensibles, supprimer le repli, ou au minimum le rendre bruyant : notification, délai, alerte. Même logique pour les liens de connexion par courriel.

Traiter l’enrôlement comme un événement de sécurité. L’ajout d’une nouvelle passkey à un compte doit notifier l’utilisateur sur ses autres canaux et, pour les comptes sensibles, alerter une équipe. C’est l’instant précis où une compromission cesse d’être un accident pour devenir un domicile.

Durcir le déverrouillage local. Si le code de l’appareil protège le coffre, il doit avoir la robustesse d’un facteur d’authentification : pas quatre chiffres, pas un zigzag tracé sur l’écran dont la trace grasse reste lisible en contre-jour. Cela s’impose par la gestion du parc, et on l’oublie parce que cela semble relever du confort.

Protéger la session, pas seulement la connexion. Durées de session raisonnables, réauthentification pour les opérations sensibles, liaison de la session à l’appareil quand la plateforme le permet. La passkey a poussé l’attaquant vers le cookie ; il faut avoir la courtoisie de le suivre.

# Côté service : répartition des identifiants WebAuthn des comptes d'administration
# selon les indicateurs de sauvegarde. Lecture seule, sur une table hypothétique :
# adapter les noms de base, de tables et de colonnes au schéma réel.
psql -d auth -c "
  SELECT backup_eligible, backup_state, count(*)
  FROM webauthn_credentials
  WHERE account_id IN (SELECT id FROM accounts WHERE role = 'admin')
  GROUP BY 1, 2;"

Cette requête n’a de sens que si le service enregistre les indicateurs de sauvegarde ; s’il ne le fait pas, c’est la première chose à corriger. Elle répond à une question d’une simplicité désarmante : parmi les comptes d’administration, combien reposent sur une clé qui existe en plusieurs exemplaires, quelque part, chez quelqu’un ?

Ce que je ne sais pas

Je ne sais pas mesurer la solidité réelle des procédures de récupération des grands fournisseurs. J’en connais les descriptions publiques. Je ne sais pas combien de tentatives de prise de contrôle elles déjouent, ni lesquelles réussissent. Personne ne publie ces chiffres de manière vérifiable, et mon raisonnement repose donc sur la structure du problème, pas sur une mesure. Il est possible que ces procédures soient bien meilleures que ce que ma prudence de vieillard suppose. Je le souhaite ; je ne le parie pas.

Je ne sais pas où en sera la portabilité dans deux ans. Si l’échange standardisé d’identifiants entre fournisseurs devient universel et simple, la section sur le verrou d’écosystème vieillira vite, et j’en serai ravi. S’il reste partiel ou divergent, elle restera d’actualité, et j’en serai moins ravi, mais j’aurai eu raison, ce qui console mal.

Je ne sais pas comment évolueront les référentiels publics. Les positions des organismes de normalisation et des agences sur les authentificateurs synchronisables ont évolué pendant le déploiement, dans le sens d’une acceptation encadrée. Je n’ai pas de certitude sur leur état à la date de lecture ; les lecteurs soumis à un référentiel particulier doivent consulter sa version en vigueur plutôt que les humeurs d’un papy.

Je ne sais pas si le vol de session restera le terrain principal. Des mécanismes de liaison des sessions à l’appareil sont en cours de conception et de déploiement dans les navigateurs. S’ils se généralisent, l’attaquant cherchera encore ailleurs. Je parierais sur la récupération et sur l’ingénierie sociale envers les équipes de support, mais c’est un pari, pas un constat, et je n’ai jamais rien gagné aux courses.

Ce qui reste

Les passkeys font ce qu’elles promettent, et c’est assez rare pour qu’on s’y attarde avec une émotion contenue. Elles rendent l’hameçonnage d’identifiants inopérant, elles vident de sens les bases de secrets volées, elles retirent à l’utilisateur une décision qu’il prenait mal depuis trente ans. Tout cela est acquis, et tout cela justifie de les déployer sans attendre la fin de ce paragraphe.

Trois choses me semblent tenir au-delà de l’enthousiasme. Que la passkey synchronisée et la passkey liée à un appareil sont deux objets différents, qu’il faut nommer séparément et choisir selon l’enjeu. Que la sécurité d’une passkey synchronisée est celle du coffre qui la synchronise, c’est-à-dire d’un compte, de ses appareils et de sa procédure de récupération, et qu’il faut donc savoir quel est ce compte et qui le gouverne. Et que l’événement critique a changé de place : ce n’est plus la connexion, c’est l’ajout d’un appareil ou d’une clé, et nos journaux, fidèles à eux-mêmes, regardent encore la porte d’entrée pendant qu’on passe par la cave.

Reste une question que cet éditorial a contournée à chaque section avec l’élégance d’un chat autour d’une baignoire. Toutes les passkeys du monde finissent par s’appuyer sur un guichet : quelqu’un, ou quelque chose, qui accepte de vous rendre l’accès quand vous ne pouvez plus le prouver. C’est ce guichet que l’attaquant a désormais intérêt à tromper. Il est ouvert du lundi au vendredi, parfois le samedi matin, et il mérite un éditorial pour lui seul.

🐝 Ce qui arrive si on s’en passe

Une organisation qui déploie des passkeys synchronisées sans gouverner le coffre qui les porte perd le moyen de couper un accès : au départ d’un salarié, ses clés professionnelles restent valides sur tous les appareils de son compte personnel, et aucun inventaire ne dit combien il y en a. Un appareil ajouté par un attaquant à ce compte hérite de l’ensemble des accès sans déclencher la moindre alerte, et chaque connexion qui suit présente une signature irréprochable, que l’analyse après incident ne peut distinguer de l’usage légitime. La suspension du compte par le fournisseur, enfin, ferme d’un coup toutes les portes à leur propriétaire légitime, qui découvre alors que le guichet capable de les rouvrir ne lui doit rien.

🦫 Explication de la marmotte 🍫

Une passkey remplace le mot de passe par une paire de clés : une clé privée, gardée secrète dans un appareil, et une clé publique, confiée au site. La paire est créée pour un seul site. À chaque connexion, le site envoie un défi, un nombre tiré au hasard. Le navigateur y ajoute l’adresse réelle de la page, et l’appareil signe le tout avec la clé privée. Le site vérifie la signature, le défi et l’adresse. Une fausse page, hébergée ailleurs, ne peut donc pas obtenir une signature valable pour le vrai site, même si l’utilisateur se trompe. Le site ne stocke plus de secret réutilisable. Il existe deux sortes de passkeys. Celle liée à un appareil ne quitte jamais son composant : la perdre, c’est la perdre. Celle qui est synchronisée est copiée, chiffrée, vers tous les appareils d’un même compte chez un fournisseur. Sa sécurité dépend alors de ce compte : de l’ajout d’un nouvel appareil, du code qui déverrouille le téléphone et de la procédure qui permet de récupérer le compte perdu. Quelqu’un qui ajoute un appareil au compte obtient toutes les clés d’un coup, et ses connexions ressemblent ensuite à des connexions normales. Les passkeys ne protègent pas non plus la session ouverte après la connexion, ni un appareil piraté, ni un mot de passe laissé en secours. Enfin, changer de fournisseur reste difficile.

Pages voisines

La citent

Les comptes de service oubliés

Les passkeys, et ce qui se déplace

Elle cite

: les deux pages se citent l’une l’autre.

Les passkeys, et ce qui se déplace

Une bonne nouvelle, pour une fois

Ce que règle la liaison à l’origine

Ce que la liaison à l’origine ne couvre pas

Synchronisées ou liées à un appareil : deux objets sous un même mot

L’attestation, espèce en voie de raréfaction

Où va la clé quand elle se synchronise

Le compte de plateforme, nouveau maître des clés

Le verrou d’écosystème

Le meilleur argument contre cet éditorial

Ce que je ferais, concrètement

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines