Les clés d’authentification remplacent les mots de passe chez Apple, Google et Microsoft — ce qui change concrètement pour vous
En mai 2022, Apple, Google et Microsoft annonçaient conjointement un soutien élargi à un standard d’authentification sans mot de passe fondé sur WebAuthn et FIDO2. En 2024, Apple avait basculé par défaut les comptes iCloud vers les clés d’authentification, Google en avait enrôlé plus de 800 millions, et Microsoft commençait à supprimer complètement les mots de passe des nouveaux comptes grand public. Malgré cette ampleur, la plupart des utilisateurs considèrent encore les clés d’authentification comme une simple variante de l’authentification à deux facteurs — ce n’est pas le cas. Les clés d’authentification représentent un modèle d’authentication fondamentalement différent, et en comprendre le fonctionnement explique pourquoi elles éliminent des catégories entières d’attaques que les mots de passe ne peuvent pas prévenir.
La thèse centrale : les clés d’authentification remplacent le modèle secret partagé des mots de passe par de la cryptographie asymétrique. Lorsque vous créez une clé d’authentification, votre appareil génère une paire de clés — une clé privée stockée dans un enclave sécurisée matériellement sur votre appareil, et une clé publique enregistrée auprès du service. Lors de la connexion, le service envoie un défi cryptographique ; votre appareil le signe avec la clé privée et renvoie la signature. Le serveur vérifie la signature par rapport à votre clé publique. À aucun moment un secret n’est transmis, et la clé privée ne quitte jamais votre matériel. Comparez cela avec l’authentification par mot de passe, où votre secret — ou un de ses dérivés — doit être transmis au serveur à chaque connexion.
WebAuthn sous le capot
WebAuthn (Web Authentication API) est le standard du W3C que les navigateurs implémentent pour exposer les fonctions de clé d’authentification aux sites web. L’API a été finalisée en tant que Recommandation W3C en mars 2019 (niveau 1) et mise à jour en avril 2021 (niveau 2). Lorsqu’un site appelle navigator.credentials.create(), le navigateur délègue à un authenticator — soit un authenticator plateforme (l’enclave sécurisée de votre appareil, comme Apple Secure Enclave, Android StrongBox ou la puce TPM de Windows Hello), soit un authenticator itinérant (une clé matérielle comme un YubiKey).
L’authenticator génère une paire de clés ES256 (ECDSA avec courbe P-256) ou RS256 pour cette partie fiable spécifique — identifiée par son domaine enregistré (RP ID). La clé privée est scellée dans l’élément sécurisé, où elle ne peut être utilisée qu’après une vérification locale de l’utilisateur (biométrie ou code PIN). La clé publique et un identifiant d’identification (credential ID) sont envoyés au serveur et stockés dans sa base de données. Pas de hachage de mot de passe, pas de rounds PBKDF2, pas de facteur de coût bcrypt — juste une clé publique mathématiquement inutile à un attaquant sans la clé privée correspondante.
L’étape d’attestation
Lors de l’enregistrement, les authenticators peuvent éventuellement produire une déclaration d’attestation — une déclaration signée cryptographiquement mentionnant la marque, le modèle et le niveau de sécurité de l’appareil, signée par une chaîne de certificats remontant au FIDO Alliance Metadata Service (MDS). Cela permet aux services à haute sécurité (banques, gouvernements) de vérifier qu’ils acceptent des identifiants provenant d’un véritable élément sécurisé matériel, et non d’une émulation logicielle. Les services grand public ignorent généralement l’attestation et acceptent tout authenticator conforme.
La résistance au phishing est structurelle, pas comportementale
Le phishing de mots de passe fonctionne car les utilisateurs ne peuvent pas distinguer de manière fiable accounts.google.com de accounts.g00gle.com sous pression temporelle. Même les clés 2FA matérielles qui implémentent TOTP (mots de passe uniques temporaires) sont phishables — l’attaquant relaie le OTP en temps réel vers le site légitime. Les clés d’authentification ferment cette surface d’attaque au niveau du protocole.
La clé privée est liée au RP ID — le domaine enregistré. Lorsque la cérémonie d’assertion WebAuthn commence, le navigateur inclut le RP ID dans les données signées. Si vous êtes sur un site de phishing avec un domaine différent, le RP ID dans l’assertion ne correspondra pas à la liaison de l’identifiant, et l’authentification échoue. L’attaquant ne peut pas rediriger l’assertion vers le site légitime car la signature n’est pas transférable — elle a été calculée avec l’origine du site de phishing intégrée. Ce n’est pas un problème d’éducation de l’utilisateur avec un système de clé d’authentification ; c’est impossible par construction.
Le rapport 2023 du FIDO Alliance Passkey Central a documenté que les identifiants conformes à CTAP2.1 (Client to Authenticator Protocol version 2.1) résistent au phishing en temps réel, aux attaques adversary-in-the-middle (AiTM) et au credential stuffing. Les attaques proxy AiTM — qui contournent avec succès le SMS OTP et le TOTP — n’ont aucun vecteur d’attaque équivalent contre les signatures d’assertion WebAuthn.
Clés d’authentification synchronisées : commodité vs sécurité liée à l’appareil
Le modèle FIDO2 original était lié à l’appareil : un authenticator matériel détenait une copie de la clé privée. Perdre l’appareil signifiait perdre l’identifiant. C’était sécurisé mais créait des problèmes d’utilisabilité — c’était un non-départ pour une adoption massive. L’extension FIDO Alliance de 2022 a introduit les identifiants multi-appareils, communément appelés clés d’authentification synchronisées (sync passkeys).
Avec les clés d’authentification synchronisées, la matière de la clé privée est chiffrée et synchronisée entre vos appareils via le cloud du fournisseur de plateforme. Apple synchronise via iCloud Keychain avec un chiffrement de bout en bout utilisant des clés dérivées de votre code d’accès appareil. Google synchronise via Google Password Manager, également chiffré de bout en bout. Microsoft synchronise via Windows Hello et, depuis 2024, prend en charge la synchronisation inter-appareils via l’application Microsoft Authenticator.
Cela crée un compromis que les équipes de sécurité débattent activement. Les clés d’authentification synchronisées sont nettement plus sécurisées que les mots de passe — elles restent impossibles à phisher, et aucune fuite serveur ne les expose — mais le modèle de menace passe de la compromission de l’appareil à la compromission du compte cloud associé au code PIN/biométrie de l’appareil. Pour la plupart des utilisateurs, c’est un compromis acceptable ; leur compte Google ou Apple protège déjà des données bien plus sensibles. Pour les cibles de haute valeur (journalistes, dirigeants, militants), les clés d’authentification liées à l’appareil sur une clé matérielle FIDO2 dédiée (série YubiKey 5, à partir de 50 USD, ou clé Google Titan à 30 USD) restent l’option la plus robuste.
Authentification inter-appareils
Lorsque vous essayez de vous connecter à un site sur un navigateur de bureau alors que votre clé d’authentification est stockée sur votre téléphone, WebAuthn prend en charge un flux d’authentification inter-appareils utilisant le transport hybride CTAP2. Le navigateur de bureau affiche un code QR ; votre téléphone le scanne et établit un canal BLE (Bluetooth Low Energy) chiffré. Le téléphone signe l’assertion localement (après vérification biométrique) et transmet la signature de retour via le canal chiffré. Votre clé privée ne traverse jamais la liaison BLE — seule la réponse au défi signée le fait. Cela nécessite que le Bluetooth soit activé sur les deux appareils, ce qui est un léger point de friction.
Que se passe-t-il en cas de fuite serveur
La fuite RockYou2024 de 2024 a compilé 9,9 milliards de mots de passe en clair issus de fuites antérieures. Les bases de données de mots de passe sont précieuses pour les attaquants précisément parce que les mots de passe sont réutilisés — 65 % des utilisateurs réutilisent le même mot de passe sur plusieurs sites selon le Google 2023 Password Manager Report. Avec les clés d’authentification, il n’y a pas de mot de passe à voler dans la base de données. Le serveur ne stocke que votre clé publique. Même si un attaquant exfiltre toute la base de données de clés d’authentification, il obtient une collection de clés publiques — mathématiquement équivalent à une liste de cadenas sans clés. Il ne peut pas s’authentifier en votre nom, ne peut pas casser les clés hors ligne, et ne peut pas les utiliser pour attaquer d’autres services.
Services encore bloqués sur les mots de passe
À la mi-2025, la prise en charge des clés d’authentification est répandue mais inégale. GitHub a ajouté la prise en charge en juillet 2023. Shopify l’a activée début 2024. Les principaux retardataires incluent de nombreux portails bancaires (notamment les credit unions et les banques régionales), les services gouvernementaux, les VPN d’entreprise, et tout service qui n’a pas mis à jour sa stack d’authentification depuis 2020. Les applications Java EE et PHP héritées utilisent souvent des bibliothèques d’authentification qui n’ont pas intégré les composants côté serveur FIDO2 (comme java-webauthn-server par Yubico ou php-webauthn par lbuchs).
Pour les services qui exigent encore des mots de passe, l’approche pratique est un gestionnaire de mots de passe avec des identifiants aléatoires robustes — Bitwarden (open source, niveau gratuit), 1Password (2,99 USD par mois) ou le trousseau de la plateforme. Ce n’est pas équivalent à la sécurité des clés d’authentification — votre coffre de gestionnaire de mots de passe est chiffré avec un mot de passe maître qui pourrait être phishé — mais cela élimine la réutilisation des identifiants, qui est le vecteur d’attaque le plus courant.
Étapes concrètes
- Audit de prise en charge des clés d’authentification dès maintenant : Consultez passkeys.directory (un registre maintenu par la communauté) pour voir quels services que vous utilisez prennent déjà en charge les clés d’authentification. Activez-les sur Google, Apple ID, Microsoft, GitHub, et tout autre service listé.
- Comprenez votre modèle de synchronisation : Si vous utilisez des appareils Apple, vos clés d’authentification se synchronisent par défaut via iCloud Keychain. Si vous utilisez Android, elles se synchronisent via Google Password Manager. Vous pouvez également enregistrer les clés d’authentification dans 1Password ou Bitwarden si vous préférez un stockage neutre vis-à-vis du fournisseur — ces deux derniers ont ajouté la prise en charge des clés d’authentification en 2023.
- Les comptes à haute sécurité nécessitent des clés matérielles : Pour votre messagerie principale, votre registraire de domaine et vos comptes financiers, associez la configuration de la clé d’authentification à une clé matérielle FIDO2 de secours. Enregistrez deux clés pour avoir une de rechange. Le YubiKey 5C NFC (55 USD) couvre USB-C et NFC, gérant presque tous les appareils.
- Ne supprimez pas encore votre ancienne 2FA : Lorsque vous ajoutez une clé d’authentification, conservez votre authenticator TOTP existant ou votre sauvegarde par SMS pour la récupération du service. Supprimez le mot de passe (là où le service le permet) une fois que vous avez confirmé que la clé d’authentification fonctionne sur tous vos appareils.
- Les services hérités obtiennent des mots de passe uniques : Pour tout service sans prise en charge de clé d’authentification, générez un mot de passe aléatoire unique dans votre gestionnaire de mots de passe. N’attendez pas que le service se mette à jour pour améliorer votre posture de sécurité dès aujourd’hui.
Les clés d’authentification ne sont pas une technologie future — elles sont déployées à grande échelle dès maintenant. L’écart entre les services qui les prennent en charge et les utilisateurs qui les ont adoptées est un problème de sensibilisation, pas technique. Chaque clé d’authentification que vous créez retire un identifiant qui pourrait être phishé, divulgué ou deviné. Commencez par les comptes les plus importants.