YubiKey et clés FIDO2 : tout ce qu'on ne vous a pas dit

Un chercheur en sécurité perd sa clé dans un taxi à Berlin, un dimanche soir. Une seule clé. Quarante-sept comptes verrouillés derrière. Il a passé trois semaines à récupérer ses accès un par un, par des procédures de recovery toutes différentes, certaines impossibles sans appeler un support qui ne répond qu’aux heures de bureau d’un autre fuseau. « Je pensais qu’une clé suffisait. » Je l’entends à peu près une fois par mois. C’est, et de loin, la défaillance la plus fréquente que je rencontre avec les clés hardware : on en achète une, on l’enregistre sur deux ou trois comptes, et on ne pense jamais au scénario de la perte avant qu’il arrive.

Le piège habituel

Acheter une clé hardware n’est pas une stratégie de sécurité. La clé est un outil. La stratégie, c’est le déploiement : combien de clés, sur quels comptes, où vit la backup, comment vous gérez la perte, comment vous gérez le cycle de vie. Le discours dominant s’arrête à « prends une YubiKeyClé d'authentification matérielle de Yubico, supportant FIDO2/WebAuthn, OTP, PIV, OpenPGP.Voir le lexique, c’est le meilleur MFAAuthentification à plusieurs facteurs : combiner deux preuves d'identité indépendantes pour se connecter.Voir le lexique ». C’est vrai et c’est insuffisant. C’est exactement comme dire « prends un extincteur » sans préciser combien, où, et qui sait s’en servir.

La configuration que je vois le plus souvent : une seule clé, enregistrée sur Google et GitHub, et toutes les méthodes de récupération faibles toujours actives en parallèle. SMS de secours sur un numéro mobile ordinaire, e-mail de récupération sans second facteur, questions de sécurité dont les réponses traînent sur LinkedIn. Dans cette configuration, la clé ne change pas radicalement votre exposition : elle ajoute une porte blindée à côté d’une fenêtre ouverte. Un attaquant qui veut entrer ne force pas la porte blindée. Il déclenche un SIM swapAttaque où un fraudeur convainc votre opérateur de basculer votre numéro vers sa propre SIM.Voir le lexique, intercepte le SMS de secours, et réinitialise l’accès sans jamais croiser votre clé.

L’autre piège est plus subtil et plus douloureux : la clé fait son travail trop bien. Le FIDO2Standard d'authentification forte par clé cryptographique matérielle, résistante au phishing.Voir le lexique est conçu pour qu’aucune copie de la credential ne quitte la clé. C’est précisément ce qui le rend inviolable au phishing — et c’est aussi ce qui vous enferme dehors le jour où la clé tombe dans le caniveau. Il n’y a pas de « mot de passe oublié » pour un objet physique perdu. La seule parade, c’est la redondance : avoir prévu une seconde clé avant l’incident. La règle de base tient en une phrase : chaque compte critique doit avoir deux clés enregistrées, et les méthodes de recovery alternatives doivent être au moins aussi solides que la clé elle-même. Tout le reste découle de là.

Inventaire réel : ce que fait vraiment une clé, et contre quoi

Une clé hardware n’est pas un objet à fonction unique. Selon le protocole qu’elle parle avec le service, elle vous protège contre des choses différentes. Confondre ces protocoles, c’est croire qu’on est couvert là où on ne l’est pas.

Le protocole central, celui qui justifie l’achat à lui seul, c’est FIDO2Standard d'authentification forte par clé cryptographique matérielle, résistante au phishing.Voir le lexique et son interface navigateur WebAuthnAPI navigateur qui permet l'authentification FIDO2 sur les sites web.Voir le lexique. Voici ce qu’il fait que rien d’autre ne fait : quand vous enregistrez une clé sur un site, elle génère une paire de clés cryptographiques liée au domaine exact du service — accounts.google.com, par exemple. À chaque connexion, la clé vérifie que le domaine qui demande l’authentification correspond au domaine d’enregistrement. Une page de phishingAttaque par ingénierie sociale qui pousse la cible à donner ses identifiants ou exécuter du code.Voir le lexique hébergée sur accounts-google.com ou google.secure-login.example ne correspond pas. La clé refuse de signer. Elle ne demande pas votre avis, elle ne vous fait pas confiance pour repérer la faute dans l’URL : elle constate l’écart de domaine et s’arrête. Aucun code TOTPCode à 6 chiffres généré toutes les 30 secondes par une app (Google Authenticator, Authy, etc.).Voir le lexique, aucun SMS, aucune notification push ne fait ça — tous ces facteurs peuvent être saisis sur une fausse page et rejoués en temps réel par l’attaquant. C’est la seule défense anti-phishing qui résiste à un opérateur humain compétent en face.

Les autres protocoles sont des bonus utiles, pas le cœur. L’OTP : la clé peut générer un code à usage unique pour les sites qui ne supportent pas encore FIDO2. La PKISystème qui gère les certificats et clés publiques pour authentifier les identités.Voir le lexique via PIV (Personal Identity Verification) : la clé stocke des certificats x.509 pour l’authentification SSH par certificat, le login Windows par smartcard, la signature de documents — la clé privée ne quitte jamais le matériel, donc un laptop compromis ne permet pas de l’exfiltrer. PGPSystème de chiffrement de bout en bout et de signature, créé par Phil Zimmermann en 1991.Voir le lexique : la clé signe vos commits Git et déchiffre vos e-mails sans que la clé privée touche le disque. Dans tous ces cas, le principe est identique : l’opération cryptographique se fait sur la puce, pas sur la machine hôte. C’est ce qui transforme un secret « copiable » en un secret « inarrachable ».

Un détail technique change tout dans la pratique, et personne ne vous l’explique au moment de l’achat : la différence entre credential résidente et non-résidente. Une credential non-résidente (la forme historique, dite « server-side ») n’est pas stockée sur la clé — c’est le service qui conserve un blob chiffré qu’il renvoie à la clé au moment de l’authentification. La clé peut donc en gérer un nombre illimité, mais elle ne « sait » rien : elle ne peut pas lister vos comptes, et vous devez toujours fournir un identifiant pour démarrer la connexion. Une credential résidente (discoverable, celle qu’exigent les passkeysImplémentation grand public de FIDO2 : clé d'authentification stockée et synchronisée par Apple/Google/Microsoft.Voir le lexique) est, elle, stockée dans la puce : la clé devient capable de se présenter seule, sans identifiant, ce qui permet le login « sans nom d’utilisateur ». L’envers de la médaille est dur : la mémoire est limitée — de l’ordre de 25 credentials résidentes sur une YubiKey 5, davantage sur les générations récentes — et surtout, une credential résidente ne peut pas être copiée ni exportée. Si vous bâtissez tout sur des passkeys résidentes et que vous perdez la clé, vous ne « récupérez » rien : vous repartez de la procédure de secours du service. C’est exactement pour ça que la seconde clé doit, elle aussi, recevoir sa propre credential résidente sur chaque compte concerné.

Maintenant, le modèle de menace honnête. Contre quoi une clé hardware ne vous protège pas. Elle ne protège pas un compte sur lequel une méthode de récupération faible reste active : l’attaquant passe par le maillon faible, point. Elle ne protège pas contre la perte physique si vous n’avez pas de backup : vous devenez votre propre adversaire. Elle ne protège pas contre un service mal codé qui accepte un downgrade vers un facteur plus faible « parce que vous avez oublié votre clé » — et beaucoup de services grand public le font encore, en proposant un repli SMS dès que la clé n’est pas branchée. Et elle ne protège pas contre l’attaquant qui a un accès root persistant à votre machine pendant que la clé est branchée — il ne vole pas la clé, il détourne une session déjà authentifiée. La clé sécurise l’authentification, pas la session qui suit. Comprendre ce périmètre, c’est arrêter de croire qu’un bout de plastique à 50 € est une cape d’invincibilité.

Reste la question du toucher. Sur la majorité des clés, l’authentification FIDO2 exige une « presence check » : un contact physique sur le disque doré. Ce geste prouve qu’un humain est présent, ce qui bloque l’usage à distance par un malware qui aurait accès au port USB. Mais un simple contact n’est pas une preuve d’identité : quiconque a la clé en main peut toucher. Les modèles biométriques ajoutent une vérification d’empreinte locale — la clé ne signe que si l’empreinte enregistrée correspond. Pour un poste partagé, un open space, ou un profil qui craint le vol opportuniste de la clé branchée, cette nuance compte. Pour la plupart des usages, le contact physique suffit, parce que l’attaquant qui a déjà votre clé en main a probablement aussi votre laptop, et le problème n’est plus le même.

La bonne approche : la règle des deux clés, et le déploiement par criticité

La bascule pragmatique tient en un mot : redondance avant migration. Vous n’activez jamais une clé sur un compte critique sans en enregistrer une seconde dans la même session. Pas « plus tard », pas « quand j’aurai reçu la deuxième » : dans la même session, ou vous ne touchez pas au compte. C’est contre-intuitif parce qu’on a envie de sécuriser vite. Mais une clé unique sur un compte critique, c’est un piège à retardement que vous vous tendez à vous-même.

Concrètement, j’applique systématiquement la règle des deux clés, idéalement de deux modèles différents. Une clé primaire — sur vous en permanence, porte-clés ou poche intérieure, c’est elle qui sert au quotidien. Une clé backup — dans un lieu physique distinct : coffre à domicile, coffre en banque, ou chez un proche de confiance, jamais dans le même sac que la primaire. Si vous perdez le sac, vous ne devez pas perdre les deux clés d’un coup. Deux modèles différents, c’est l’assurance contre un défaut de série ou un rappel fabricant : si une faille touche un modèle, l’autre reste valide. Pour les profils très exposés — dirigeants, journalistes, personnes sous menace ciblée — une troisième clé chez un tiers de confiance couvre le scénario extrême : vous êtes incapacité, à l’étranger sans bagage, ou la backup est inaccessible.

L’ordre de déploiement n’est pas anodin. On commence par le compte dont la chute fait tomber tous les autres, puis on descend par criticité décroissante. La séquence que je recommande : d’abord le gestionnaire de mots de passe, clé de voûte de toute la vie numérique ; ensuite l’e-mail principal, parce qu’il est le vecteur de récupération de presque tout le reste ; puis le compte d’identité fédérée (Google, Apple, Microsoft) qui sert souvent de SSOMécanisme qui permet de s'authentifier une fois pour accéder à plusieurs applications.Voir le lexique vers une dizaine de services tiers ; puis GitHub/GitLab si vous développez, et enfin les comptes bancaires et crypto. Pour chaque compte : on enregistre la clé primaire, on enregistre la backup, on télécharge les codes de récupération offline, on garde temporairement l’ancien MFA actif, et on ne le désactive qu’après avoir vérifié que tout fonctionne sur les deux clés. La migration s’étale sur deux à trois semaines, pas sur une soirée énervée.

Dernier point, le seul test qui compte vraiment : déconnectez-vous d’un compte et reconnectez-vous uniquement avec la clé backup, une fois, pour de bon. Tant que vous n’avez pas exécuté ce flux, vous ne savez pas s’il marche — vous l’espérez. Un plan de recovery non testé est un plan qui échoue exactement le jour où vous en avez besoin.

Choisir le bon modèle sans se tromper

Le marché paraît compliqué, il ne l’est pas. Trois questions suffisent à trancher : quel connecteur, quels protocoles, et quel niveau de vérification physique. Le reste est du marketing.

Le connecteur d’abord, parce que c’est le piège le plus bête : une clé USB-A dans un laptop qui n’a que de l’USB-C est un presse-papier. Regardez vos ports avant d’acheter. La plupart des ultrabooks récents (MacBook, Dell XPS, Surface) sont tout USB-C ; les tours et beaucoup de PC pro gardent de l’USB-A. Le NFC, lui, n’est pas un luxe : c’est ce qui permet d’approcher la clé du dos du téléphone pour s’authentifier sur mobile, sans adaptateur, sans dongle. Pour quiconque utilise son téléphone — c’est-à-dire tout le monde — le NFC est non négociable.

Le modèle de référence reste la YubiKey 5 NFC (USB-A + NFC) ou sa jumelle 5C NFC (USB-C + NFC). Elles parlent tous les protocoles utiles : FIDO2Standard d'authentification forte par clé cryptographique matérielle, résistante au phishing.Voir le lexique/WebAuthn, OTP, PIVSystème qui gère les certificats et clés publiques pour authentifier les identités.Voir le lexique pour les certificats, OpenPGPSystème de chiffrement de bout en bout et de signature, créé par Phil Zimmermann en 1991.Voir le lexique. C’est le bon défaut pour 90 % des gens et pour un premier déploiement d’entreprise, parce que ça couvre tous les cas d’usage sans avoir à racheter du matériel six mois plus tard. Les variantes Nano (5 Nano, 5C Nano) sont des versions miniatures qui restent branchées en permanence dans le port : pratique au bureau pour ne jamais la perdre, mais c’est exactement ce qu’on oublie dans un laptop qu’on prête ou qu’on se fait voler. À réserver à un poste fixe qui ne bouge pas.

Les modèles biométriques (YubiKey Bio) ajoutent l’empreinte digitale décrite plus haut : la clé ne signe que pour la bonne personne. Le prix monte, la couverture protocolaire se réduit souvent au FIDO2 seul, mais pour un dirigeant ou un profil sous menace, l’assurance qu’une clé volée branchée ne suffit pas vaut le surcoût. Côté alternatives, la Nitrokey, conçue en Allemagne et au matériel ouvert, séduit les profils qui refusent de dépendre d’un fournisseur unique ou veulent auditer le firmware — l’outillage de gestion est moins léché, la fonction équivalente sur FIDO2 et OpenPGP. La Google Titan, elle, fait du FIDO2 fiable et rien d’autre : non programmable, simple, correcte comme backup bon marché à côté d’une YubiKey complète. C’est d’ailleurs une stratégie saine que de panacher : une YubiKey 5 comme primaire polyvalente, une seconde clé d’une autre marque ou d’un autre modèle comme backup, pour ne pas dépendre d’une seule lignée de firmware.

Cycle de vie, reset et révocation

Une clé n’est pas un achat ponctuel, c’est un actif à gérer dans le temps — exactement comme un trousseau de clés physiques. Trois moments comptent : la perte, l’effacement, et le départ.

À la perte de la clé primaire, le scénario est confortable si vous avez fait le travail en amont : vous continuez à vous connecter avec la backup, vous commandez un remplacement, vous l’enregistrez sur tous les comptes, et seulement ensuite vous retirez la credential de la clé perdue, compte par compte. Attention au piège : sur beaucoup de services, « retirer une clé » supprime une credential côté serveur, mais la clé physique perdue, si elle est retrouvée, reste techniquement valide pour les comptes où vous n’avez pas fait le ménage. D’où l’inventaire — savoir précisément sur quels comptes chaque clé est enregistrée. C’est ykman qui vous le dit : ykman fido credentials list énumère les credentials résidentes d’une clé, ykman info donne son état général. Sans cet outil, vous gérez à l’aveugle.

L’effacement (reset) est l’opération qu’on néglige jusqu’au jour où on en a besoin sous pression. ykman fido reset efface toutes les credentials FIDO2 résidentes et remet le PIN à zéro ; ykman piv reset repart de zéro côté certificats ; les slots OpenPGP et OTP se réinitialisent séparément. Les cas d’usage : revente d’une clé, clé héritée d’un collègue parti, ou clé suspectée compromise qu’on remet à neuf avant réemploi. Le jour où vous revendez ou recyclez une clé sans la reset, vous laissez potentiellement des credentials et un certificat exploitables à l’acheteur suivant. Connaître ces commandes à froid, c’est ne pas improviser à chaud.

En entreprise, la révocation est le maillon qu’on oublie de câbler. Une clé doit être liée à une identité dans l’IAMGestion centralisée des identités et des accès aux ressources.Voir le lexique, et le départ d’un collaborateur doit déclencher l’invalidation de ses credentials au même titre que la désactivation de son compte e-mail. Une credential FIDO2 orpheline — valide, rattachée à un compte encore actif, dans la poche d’un ex-salarié — est exactement le genre de dette de sécurité invisible qui ne se voit qu’à l’incident. Le mode entreprise des clés (attestation, configuration verrouillée, PIN imposé) existe précisément pour rendre ce parc auditable. La même logique vaut pour le reset : c’est une procédure documentée, pas un geste individuel laissé à l’initiative de chacun.

Ce que ça implique concrètement

Erreurs qu’on voit tout le temps

• Une seule clé, pas de backup. L’erreur reine. Ça marche parfaitement jusqu’au jour où la clé tombe dans les toilettes d’un aéroport. Ce n’est pas une question de « si » mais de « quand ».
• La backup enregistrée sur certains comptes seulement. On l’ajoute sur Google et GitHub, on oublie le gestionnaire de mots de passe. Résultat : à la perte de la primaire, on garde l’accès à l’accessoire et on perd l’accès au coffre central.
• Codes de récupération jamais sauvegardés. C’est le filet de sécurité ultime. Perdus en même temps que la clé, la récupération devient un chemin de croix, parfois un cul-de-sac définitif.
• Primaire et backup dans le même sac. Deux clés, un seul point de défaillance physique. Un vol de sac et vous avez perdu les deux ensemble — autant n’en avoir qu’une.
• Méthodes de recovery faibles laissées actives. SMS de secours, e-mail de récupération sans MFA, questions de sécurité publiques. La clé devient décorative : l’attaquant ne l’attaque pas, il la contourne.
• Aucun test du flux backup. On enregistre la seconde clé et on ne s’en sert jamais. Le jour J, on découvre qu’un service exigeait une étape oubliée. Le plan non testé n’est pas un plan.
• Confondre clé hardware et passkey synchronisée. Une passkeyImplémentation grand public de FIDO2 : clé d'authentification stockée et synchronisée par Apple/Google/Microsoft.Voir le lexique synchronisée dans un cloud (iCloud, Google) est pratique mais ne vit pas dans une puce inarrachable : son modèle de menace diffère. Pour les comptes à plus haute valeur, la clé hardware reste le cran au-dessus.

Checklist actionnable

• N1 Acheter deux clés hardware, idéalement deux modèles (primaire + backup)
• N1 Enregistrer les deux clés sur le gestionnaire de mots de passe en premier
• N1 Enregistrer les deux clés sur l'e-mail principal et le compte d'identité fédérée
• N1 Télécharger et stocker offline les codes de récupération de chaque compte critique
• N2 Ranger la clé backup dans un lieu physiquement distinct de la primaire
• N2 Tester une connexion complète avec la seule clé backup avant de désactiver l'ancien MFA
• N2 Désactiver les méthodes de recovery faibles (SMS, e-mail non protégé) après validation
• N3 Installer ykman et inventorier les credentials enregistrés sur chaque clé
• N3 Déployer en entreprise par cercle de criticité (admin → dirigeants → fonctions sensibles)
• N3 Enregistrer une troisième clé chez un tiers de confiance pour les profils très exposés

Pour aller plus loin

La documentation officielle de Yubico(opens in a new tab) couvre en détail ykman, le mode PIV et la gestion des credentials résidentes — à lire avant tout déploiement sérieux. Les spécifications de la FIDO Alliance(opens in a new tab) et la recommandation WebAuthn du W3C(opens in a new tab) expliquent pourquoi le mécanisme de liaison au domaine rend le phishing inopérant : utile pour argumenter face à une direction qui doute du retour sur investissement. Enfin, les recommandations de l’ANSSIAuthentification à plusieurs facteurs : combiner deux preuves d'identité indépendantes pour se connecter.Voir le lexique sur l’authentification multifacteur posent le cadre attendu côté entreprise française, notamment pour les comptes à privilèges.