Mots de Passe et MFA: Migrer vers les Passkeys sans Casser Votre Recuperation

La premiere fois qu'un client m'a appele a 23h parce que son CFO avait jete son iPhone dans la piscine et perdu acces a tout, il est devenu evident qu'une passkey sans plan de recuperation est juste une facon elegante de s'enfermer dehors. Les passkeys resolvent le bon probleme: elles tuent la reutilisation de mots de passe, le phishing inverse et la majorite du MFA fatigue qui declenche des incidents aujourd'hui. Mais un deploiement bacle cree une nouvelle classe d'incident: utilisateur legitime bloque, pas de canal de reset fiable, helpdesk transforme en vecteur d'ingenierie sociale. Ce billet traite le deploiement de passkey comme un projet d'identite, pas comme un nouveau bouton sur la page de login, et parcourt la chaine protocole, recuperation, enrollment d'equipe, helpdesk, detection et checklist dans l'ordre ou elle casse reellement en production.

Ce qu'est techniquement une passkey

Une passkey est une paire de cles WebAuthn/FIDO2, en general ES256 (P-256) ou EdDSA (Ed25519), generee a l'enregistrement et liee a une origine. La cle privee ne quitte jamais l'authenticator: Secure Enclave sur iPhone, TPM 2.0 derriere Windows Hello, StrongBox sur Android, ou un token externe comme une YubiKey 5C NFC. Le serveur (la relying party) ne stocke que la cle publique, le credentialId et un compteur de signatures. Au login le serveur envoie une challenge aleatoire, l'authenticator la signe apres un geste de user-presence ou user-verification, et le serveur verifie la signature contre la cle publique stockee. Aucun secret partage a phisher, a fuiter depuis une base de donnees ou a capturer via un reverse proxy.

Pourquoi le phishing echoue au niveau du protocole

La valeur decisive est la liaison au RP ID (le domaine enregistre). Le navigateur ne signe que si l'origine appelante correspond au RP ID enregistre, et la signature couvre un clientDataHash sur l'origine et la challenge. Lors de tests contre un clone avec evilginx2, la passkey refuse simplement de signer pour le mauvais domaine, alors que TOTP est relaye a 100% parce que l'utilisateur tape volontairement le code dans une page sosie. Cette vue attaquant se reproduit en labo comme dans Phishing Red Team Autorise : Modeles, GoPhish et Garde-fous Ethiques, avec le montage web general dans Pentest Web depuis Zero: Construire un Lab Sur avec DVWA, Juice Shop et Burp Suite.

Le vrai risque: la recuperation, pas le protocole

Cartographiez comment votre fournisseur synchronise les credentials et a quoi ressemble la ceremonie de restore. Apple iCloud Keychain exige le passcode de l'appareil plus un contact de recuperation ou une cle de 28 caracteres. Google Password Manager s'appuie sur le verrouillage d'ecran de l'appareil precedent. Les gestionnaires comme 1Password et Bitwarden synchronisent la passkey via votre coffre, dont le secret maitre devient alors le vrai joyau. L'erreur qui enferme les gens: desactiver SMS et email en fallback sans configurer d'abord le nouveau chemin. Documentez le flux dans un modele de menace personnel avant de migrer; OPSEC pour Chercheurs en Securite: Modele de Menace Personnel contient le squelette que j'utilise avec clients a haut risque et journalistes.

Synchronisee vs liee a l'appareil: le mauvais debat

Une passkey synchronisee est confortable et survit a la perte d'appareil car elle vit dans le cloud du fournisseur; sa securite vaut exactement ce que vaut la recuperation de compte de ce fournisseur. Une passkey liee a l'appareil (token materiel, ou cle de plateforme sans sync) ne quitte jamais le silicium et ne survit a aucun appareil perdu sans seconde copie. La reponse mure n'est pas l'un ou l'autre: pour les comptes perso de chercheurs, combinez passkey synchronisee pour le confort et security key physique pour la resilience. Ne confondez jamais une passkey synchronisee avec une hardware-bound dans votre inventaire: l'attestation renvoyee a l'enregistrement vous dit ce que vous detenez vraiment.

Deploiement d'equipe: deux authenticators, politique dure

Ma regle pour les utilisateurs critiques: deux authenticators physiques (ex: YubiKey 5C plus YubiKey 5 Nano), enroles le meme jour, l'un range dans un coffre physique. Sur Entra ID, Okta ou Google Workspace, configurez l'attestation policy pour exiger des authenticators certifies FIDO2 L1+ sur les comptes privilegies, et desactivez le self-service enrollment sans revue pour les groupes admin. Imposez la user verification (userVerification: required), pas seulement la user presence. Le playbook poste dans Durcissement de Windows 11 pour Postes de Travail a Haut Risque couvre l'endpoint, et Durcissement macOS: Lockdown Mode, MDM et Reduction de Surface l'equivalent Apple.

Le vecteur helpdesk: la ou 80% des bypasses se produisent

MGM, Caesars et Cloudflare ont documente le meme pattern: attaquant appelle, simule perte d'appareil, helpdesk reset MFA. Avec passkey le vecteur ne disparait pas, il devient reset de passkey. Imposez une verification out-of-band: video call avec piece d'identite, ou approbation du manager via un canal separe et predefini - jamais le canal par lequel la demande est arrivee. Ajoutez un delai pour les resets a haut risque et notifiez le vrai titulaire via un second fil avant que le reset prenne effet. Chaque operation de reset est loggee, avec retention d'un an et alerte SIEM.

Detection: anomalies de reset en Sigma

Un reset hors heures suivi d'un login depuis une nouvelle geo en quelques minutes est un signal en clair. Si vous tournez Sigma, ecrivez une regle pour reset de credential/authenticator suivi d'un login depuis une ASN divergente ou un delta de voyage impossible. Exemple concret dans Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection, et patterns de hunting post-acces dans Hunting des Living-off-the-Land Binaries sous Windows avec KQL. Alertez sur l'enrollment d'un nouvel authenticator peu apres un reset: c'est le geste de persistance classique de l'attaquant.

Tuer le mot de passe? Le chemin par phases

Pas si vite. En pratique, gardez un password fort (>=20 caracteres, genere par gestionnaire) comme backup sur les comptes qui ne supportent pas encore passkey-only, et desactivez SMS partout ou possible. Sur les comptes qui le supportent (Google, Microsoft, GitHub, Apple, Cloudflare), basculez en passkey-only seulement apres 30 jours de test en parallele. Rangez les codes de backup imprimes dans un coffre, separes des authenticators. Pour le chiffrement disque et coffre-fort de mots de passe, Crypto de Disque et Sauvegardes: VeraCrypt, LUKS et Strategie 3-2-1 Resiliente montre comment appliquer 3-2-1 sans tomber sur une copie unique qui devient SPOF.

Erreurs courantes en audit

Les cinq memes reviennent toujours: 1) admin global avec une seule passkey sur un telephone personnel; 2) email de recuperation pointant vers un compte sans MFA; 3) cle de recuperation BitLocker sauvegardee dans le cloud du compte que vous essayez de recuperer - la boucle parfaite; 4) helpdesk autorise a desactiver MFA par ticket sans approbation manager; 5) passkey synchronisee marquee hardware-bound dans l'inventaire. Auditez ca avec un exercice purple team trimestriel, meme cycle que dans Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue. En red team autorise, ce sont les premiers chemins qu'on teste apres l'initial access.

Checklist de migration

Par compte critique, dans cet ordre: (a) enregistrer deux authenticators sur du materiel different; (b) verifier l'attestation, synchronisee ou liee a l'appareil; (c) imprimer les codes de backup et les sceller dans un coffre; (d) faire un essai de recuperation sans l'appareil principal; (e) retirer le fallback SMS; (f) pointer l'email de recuperation vers un compte lui-meme protege par MFA; (g) documenter la procedure de reset et l'alerter dans le SIEM. Ce n'est que quand les sept sont au vert que le compte est vraiment migre, pas au moment ou le nouveau login fonctionne.

Credentials decouvrables et login sans nom d'utilisateur

Une resident key (credential decouvrable) stocke la correspondance user-handle dans l'authenticator lui-meme, si bien que le login fonctionne sans nom d'utilisateur tape d'abord : via la Conditional UI (autofill WebAuthn), le navigateur propose directement la bonne passkey. C'est confortable mais limite en capacite - les vieux YubiKeys ne stockent qu'environ 25 resident keys, et un slot plein provoque des echecs d'enrollment silencieux, penibles a debugger pendant un deploiement. Sur des appareils partages ou kiosque, les credentials decouvrables sont aussi un risque de vie privee car une liste de comptes devient visible sur l'appareil. Choisissez deliberement entre resident (sans nom) et non-resident (credential cote serveur) selon le modele de menace de l'appareil, plutot que d'accepter le defaut.

Cross-device : le transport hybride via CTAP 2.2

Le cas reel le plus courant - se logger sur un desktop avec la passkey du telephone - passe par le transport hybride (ex-caBLE) : le desktop affiche un QR, le telephone le scanne et confirme via un controle de proximite BLE que les deux appareils sont physiquement proches. Cette exigence de proximite est exactement pourquoi les passkeys ne se phishent pas a distance comme un OTP telephonique. Testez explicitement le flux cross-device dans votre deploiement, car il echoue souvent sur un Bluetooth desactive, des reseaux d'entreprise restrictifs ou des apps authenticator obsoletes - et un utilisateur qui ne peut executer le seul chemin de recuperation est aussi enferme qu'un utilisateur sans backup.

FAQ: Les passkeys sont-elles resistantes au quantique?

Non, ES256 et EdDSA sont des courbes elliptiques classiques et ne resistent pas a un ordinateur quantique cryptographiquement pertinent. En pratique cela compte moins qu'il n'y parait: les passkeys utilisent le challenge-response, donc aucun secret reutilisable ne transite sur le fil pour etre enregistre et casse plus tard. La FIDO Alliance travaille deja sur l'attestation et les signatures PQC; cote migration rien ne change pour vous une fois que le firmware de l'authenticator et les navigateurs le livrent.

FAQ: Et si je perds tous mes appareils d'un coup?

C'est exactement a cela que sert l'enveloppe scellee: des codes de backup imprimes plus une troisieme cle materielle uniquement offline dans un coffre ou coffre bancaire resolvent le scenario de perte totale. Au niveau fournisseur, le contact de recuperation (Apple) ou un reset admin d'entreprise via canaux out-of-band verifies est votre dernier retour. Si votre seul chemin de recuperation est un SMS vers une SIM perdue, vous n'avez pas de recuperation, vous en avez l'illusion.

Conclusion et takeaway pratique

Vendredi prochain, ouvrez vos 5 comptes les plus critiques (email principal, banque, gestionnaire de mots de passe, IdP corporate, registrar de domaine). Pour chacun, enregistrez 2 passkeys sur des authenticators differents, imprimez les codes de backup, verifiez que vous pouvez vous logger sans l'appareil principal, et retirez SMS comme fallback. Documentez la procedure de recuperation dans une enveloppe scellee. Si vous n'y arrivez pas en 90 minutes par compte, vous n'etes pas encore pret a tuer le mot de passe - et c'est ok, ca fait partie du plan. Les passkeys sont un gain de securite enorme, mais seulement quand le chemin de recuperation est pris aussi au serieux que le login lui-meme.