J'ai géré suffisamment de déploiements MFA pour en connaître le schéma. On passe un an à pousser les notifications push et les codes TOTP, on déclare victoire, et dix-huit mois plus tard le rapport d'incident indique qu'un agent du service d'assistance a approuvé une réinitialisation pour quelqu'un avec un accent convaincant et un profil LinkedIn. Le contrôle n'a pas échoué parce que les gens sont stupides. Il a échoué parce que le contrôle repose encore sur un secret qu'on peut soutirer à un être humain.

C'est toute l'argumentation en faveur des clés d'accès, et je crois qu'il vaut la peine d'être direct : un mot de passe combiné à un code n'est pas résistant au hameçonnage, et les attaquants l'ont compris bien avant la plupart de nos feuilles de route. Parlons donc de ce qui change vraiment, de ce qui ne change pas, et de la façon de rallier à la fois ceux qui signent les chèques et ceux qui cliquent sur les boutons.

Quel contrôle a échoué, exactement

Un mot de passe, un code SMS, un code TOTP et une invite push partagent tous une propriété : la preuve d'identité est une valeur qui peut être relayée. Un proxy d'adversaire au milieu (Evilginx et ses variantes) se place entre l'utilisateur et la vraie page de connexion, relaie tout en temps réel, et repart avec une session. La CISA l'a énoncé clairement dans sa fiche d'information de 2022 sur la mise en œuvre du MFA résistant au hameçonnage : les codes générés par application et les notifications push valent mieux que rien, mais seuls les méthodes FIDO/WebAuthn et PKI sont qualifiées de résistantes au hameçonnage. NIST SP 800-63B dit la même chose dans un langage plus formel, et réserve ses niveaux d'assurance les plus élevés aux authentificateurs qui vérifient l'origine.

Les clés d'accès constituent le conditionnement grand public de ce modèle. L'identifiant est une paire de clés publique/privée. La clé privée ne quitte jamais l'authentificateur (un téléphone, un ordinateur portable, une clé de sécurité). Lors de la connexion, le navigateur lie la signature à l'identifiant de la partie utilisatrice, c'est-à-dire votre domaine. Si l'utilisateur se trouve sur evil.example plutôt que sur login.yourcompany.com, l'authentificateur ne dispose d'aucune clé correspondante et refuse simplement de signer. Il n'y a aucun code à saisir dans la mauvaise case. Le compte rendu publié par Cloudflare sur la campagne de hameçonnage de 2022 qui a frappé Twilio et d'autres constitue la meilleure preuve terrain que je connaisse : même leurre, mêmes attaquants, et les utilisateurs de clés matérielles n'ont pas été compromis parce que la vérification d'origine a fait son travail.

Alors quand quelqu'un me demande pourquoi on refait ça alors qu'on « a déjà déployé le MFA », ma réponse est que oui, on l'a déployé, mais dans la version à laquelle l'attaquant peut participer.

Préparer la plomberie

Avant de toucher aux utilisateurs, faites l'inventaire des parties utilisatrices. Chaque endroit où un utilisateur saisit un mot de passe aujourd'hui se trouve soit derrière votre IdP, soit pas. Ceux qui se trouvent derrière l'IdP obtiennent des clés d'accès le jour où vous activez WebAuthn comme méthode d'authentification. Ceux qui n'y sont pas constituent votre vrai projet. La bonne nouvelle, c'est que cette liste est généralement plus courte et plus embarrassante qu'on ne le croit, ce qui est motivant à sa façon.

Ensuite, prenez trois décisions d'architecture et consignez-les par écrit :

• Synchronisées ou liées à l'appareil. Apple, Google et Microsoft synchronisent maintenant les clés d'accès via leurs comptes infonuagiques. Le supplément 2024 de NIST à la norme 800-63B accepte les authentificateurs synchronisables au niveau AAL2, ce n'est donc pas une hérésie, mais cela signifie que la clé d'accès est aussi robuste que le mécanisme de récupération du compte iCloud ou Google de l'utilisateur. Pour les administrateurs et les rôles privilégiés, exigez des identifiants liés à l'appareil sur des clés matérielles et appliquez cette exigence par attestation là où votre IdP le prend en charge.
• Récupération. C'est là que tout programme sans mot de passe réintroduit discrètement un mot de passe. Décidez dès maintenant de ce qui se passe quand le téléphone tombe dans le port. Idéalement, la réponse est « une deuxième clé d'accès enregistrée » et, à défaut, un processus de vérification d'identité éprouvé, pas une conversation amicale avec le service d'assistance.
• Repli et extinction. Conservez le push ou le TOTP comme solution de repli uniquement pour une période déterminée, journalisez chaque utilisation, et examinez ce journal chaque semaine. Si un utilisateur possède une clé d'accès et reçoit quand même une invite push, quelque chose ne va pas et c'est probablement un attaquant.

Côté ingénierie, activez l'interface conditionnelle (le remplissage automatique du navigateur pour les clés d'accès) afin que le formulaire de connexion n'ait pas besoin d'un bouton distinct que personne ne clique, et testez la connexion entre appareils via le flux de code QR, car beaucoup de vos utilisateurs de bureau s'authentifieront avec le téléphone dans leur poche.

Convaincre les utilisateurs

Voici le test décisif : si votre déploiement nécessite une vidéo de formation, vous avez déjà perdu. Les clés d'accès sont le premier contrôle de sécurité de ma carrière qui soit réellement plus simple que ce qu'il remplace. Face ID, terminé. Aucun code, aucune application à ouvrir, plus de « avez-vous reçu le message texte ». Misez là-dessus, et enregistrez la clé d'accès à un moment où l'utilisateur est déjà authentifié et légèrement inoccupé, par exemple juste après une connexion réussie. N'imposez pas l'inscription un lundi matin avant le café ; vous êtes en concurrence avec leur boîte de réception, et la boîte de réception gagnera.

Mesurez et publiez deux indicateurs : le temps médian de connexion et le nombre de billets au service d'assistance pour les verrouillages. Quand les deux diminuent, et ils diminueront, dites-le aux gens. Les utilisateurs tolèrent la sécurité pour la forme ; ils apprécient sincèrement ce qui leur redonne trente secondes par jour.

Convaincre les dirigeants

Les dirigeants n'achètent pas la cryptographie à clé publique. Ils achètent trois choses : une probabilité de violation réduite, un coût de service d'assistance réduit, et ne pas voir leur nom dans les manchettes. Le DBIR de Verizon place les identifiants volés au sommet ou près du sommet des vecteurs d'accès initial année après année, donc l'argumentaire de risque s'écrit tout seul. Microsoft a soutenu pendant des années que le MFA bloque la grande majorité des tentatives de compromission de compte, et maintenant les attaquants se sont déplacés vers la partie que le MFA ne couvre pas. Présentez les clés d'accès comme la fermeture de cette brèche, pas comme une nouvelle lubie de l'équipe sécurité.

Ensuite, pilotez avec les dirigeants eux-mêmes. Donnez une clé d'accès au directeur financier avant d'en donner une à l'ingénierie. C'est le capital politique le moins coûteux que vous n'aurez jamais à dépenser, et si le directeur financier peut se connecter avec un pouce, personne dans l'entreprise ne peut prétendre que c'est trop difficile.

Les clés d'accès ne régleront pas votre processus d'arrivée, de mobilité et de départ, vos comptes de service périmés ou votre politique de réinitialisation au service d'assistance. Elles corrigent un échec précis et bien compris : le secret relayable. C'est une chose rare dans ce secteur, un contrôle à la fois plus robuste et plus agréable. Prenez cette victoire.