Les mots de passe sont le maillon faible de la sécurité en ligne depuis leur invention dans les années 1960. Malgré des décennies de campagnes de sensibilisation, 81 % des violations de données en 2025 impliquaient des identifiants compromis selon le rapport Verizon DBIR. Les passkeys — implémentation grand public de la norme FIDO2 — changent enfin la donne. En 2026, Apple, Google, Microsoft et la grande majorité des gestionnaires de mots de passe les supportent nativement. Ce guide explique le fonctionnement technique et l’implémentation concrète.
FIDO2, WebAuthn, passkeys : démêler les acronymes
FIDO2 est le nom de l’alliance de standards développée par la FIDO Alliance (Fast IDentity Online) en collaboration avec le W3C. Elle regroupe deux spécifications complémentaires : WebAuthn (Web Authentication API), implémentée dans les navigateurs, et CTAP2 (Client To Authenticator Protocol), qui définit la communication entre le navigateur et les authenticateurs physiques (clés de sécurité USB, smartphones). Ensemble, ils forment l’infrastructure technique des passkeys.
Une passkey est une paire de clés cryptographiques asymétriques (clé privée + clé publique). La clé publique est stockée sur le serveur. La clé privée reste sur l’appareil de l’utilisateur, protégée par l’enclave sécurisée du hardware (Secure Enclave d’Apple, Titan Chip de Google, TPM sur Windows). Pour s’authentifier, l’appareil signe un challenge cryptographique avec la clé privée — sans jamais la transmettre. Le serveur vérifie la signature avec la clé publique. Il n’y a rien à voler côté serveur.
Les passkeys ‘synced’ (synchronisées) sont la nouveauté principale de 2022-2023 : la clé privée est chiffrée et synchronisée entre les appareils via le cloud de l’écosystème (iCloud Keychain, Google Password Manager, Windows Hello). Cela résout le principal problème des FIDO2 hardware keys physiques — la perte du token. Si vous perdez votre iPhone, vos passkeys sont récupérables sur votre nouvel iPhone via iCloud. La sécurité est légèrement réduite par rapport aux clés hardware pures, mais reste infiniment supérieure aux mots de passe.
Pourquoi les passkeys sont résistants au phishing
L’attaque la plus courante contre les mots de passe est le phishing : une fausse page de connexion capture le mot de passe et le transmet à l’attaquant. Avec les passkeys, cette attaque devient structurellement impossible. Lors de la création d’une passkey, l’origine (le domaine du site) est liée cryptographiquement à la clé. Le navigateur vérifie l’origine à chaque authentification : si le domaine affiché est monsite.com mais que l’URL réelle est m0nsite.com, l’authentification échoue — l’utilisateur n’a même pas à réaliser qu’il est sur un site de phishing.
Cette résistance au phishing by design est l’argument principal des passkeys face aux alternatives. L’authentification à deux facteurs par SMS (2FA SMS) est vulnérable au SIM swapping et aux attaques de type real-time phishing proxy (Evilginx, Modlishka). Les applications TOTP comme Google Authenticator résistent mieux au phishing passif, mais restent vulnérables aux attaques proxy en temps réel. Les passkeys sont la première méthode d’authentification grand public qui soit cryptographiquement résistante au phishing.
En pratique, les attaquants s’adaptent. Les nouvelles techniques de contournement des passkeys ciblent la phase d’enrôlement (hijacking de compte lors de la création de la passkey) plutôt que la phase d’authentification. La protection passe par une authentification forte de l’identité initiale lors de l’enrôlement, et par des notifications proactives aux utilisateurs lors de l’ajout d’une nouvelle passkey à leur compte — les deux bonnes pratiques recommandées par la FIDO Alliance.
Implémenter WebAuthn côté serveur : les étapes clés
L’implémentation serveur de WebAuthn suit un protocole en deux phases : l’enregistrement (registration) et l’authentification (authentication). Dans les deux cas, le flux commence par une requête du client vers le serveur pour obtenir un ‘challenge’ aléatoire, se poursuit par une opération cryptographique sur l’appareil, et se termine par la vérification serveur de la signature produite. La bibliothèque simplewebauthn (JavaScript/TypeScript) simplifie considérablement l’implémentation des deux côtés.
Côté base de données, vous devez stocker pour chaque credential : l’ID du credential (credential_id, bytes), la clé publique (public_key, bytes), le compteur de signature (counter, entier incrémenté à chaque authentification pour détecter les clones de clé), l’AAGUID (identifiant du modèle d’authenticateur), et l’ID de l’utilisateur associé. Ces données sont sensibles — encrypted at rest — mais contrairement aux hash de mots de passe, elles sont inutilisables par un attaquant qui n’a pas accès à la clé privée physique.
La gestion des cas limites est la partie la plus complexe de l’implémentation. Comment gérer un utilisateur qui perd tous ses appareils ? Comment permettre d’ajouter plusieurs passkeys (un par appareil) pour le même compte ? Comment gérer la coexistence passkeys + mot de passe pendant la phase de transition ? Ces questions organisationnelles et UX doivent être résolues avant de commencer l’implémentation technique — la FIDO Alliance publie des guidelines UX détaillées pour ces scénarios.
Implémentation Node.js avec simplewebauthn (code complet)
Voici un exemple d’implémentation complète du flux d’enregistrement passkey avec Express et simplewebauthn :
// server/auth/passkey.js — Express + @simplewebauthn/server
const {
generateRegistrationOptions,
verifyRegistrationResponse,
generateAuthenticationOptions,
verifyAuthenticationResponse,
} = require('@simplewebauthn/server');
const RP_NAME = 'MonSite';
const RP_ID = 'monsite.com'; // Doit correspondre EXACTEMENT au domaine
const ORIGIN = 'https://monsite.com';
// POST /auth/passkey/register/begin
router.post('/passkey/register/begin', requireAuth, async (req, res) => {
const user = req.user;
const userCredentials = await db.credentials.findByUser(user.id);
const options = await generateRegistrationOptions({
rpName: RP_NAME,
rpID: RP_ID,
userID: user.id,
userName: user.email,
userDisplayName: user.name,
// Exclure les credentials déjà enregistrés
excludeCredentials: userCredentials.map(c => ({
id: c.credential_id,
type: 'public-key',
})),
authenticatorSelection: {
residentKey: 'required', // Passkey synced (discoverable credential)
userVerification: 'required', // Exige biométrie ou PIN
},
});
// Sauvegarder le challenge en session pour vérification
req.session.registrationChallenge = options.challenge;
res.json(options);
});
// POST /auth/passkey/register/complete
router.post('/passkey/register/complete', requireAuth, async (req, res) => {
const { body } = req;
const expectedChallenge = req.session.registrationChallenge;
try {
const { verified, registrationInfo } = await verifyRegistrationResponse({
response: body,
expectedChallenge,
expectedOrigin: ORIGIN,
expectedRPID: RP_ID,
requireUserVerification: true,
});
if (!verified) return res.status(400).json({ error: 'Vérification échouée' });
const { credentialID, credentialPublicKey, counter, aaguid } = registrationInfo;
await db.credentials.create({
user_id: req.user.id,
credential_id: Buffer.from(credentialID),
public_key: Buffer.from(credentialPublicKey),
counter,
aaguid,
created_at: new Date(),
});
delete req.session.registrationChallenge;
res.json({ success: true });
} catch (err) {
res.status(400).json({ error: err.message });
}
});État du support navigateur et plateforme en 2026
En 2026, le support des passkeys est excellent sur les plateformes principales. Safari (iOS 16+, macOS Ventura+) via iCloud Keychain : synchronisation native entre iPhone, iPad, Mac. Chrome (M108+, Android et Desktop) via Google Password Manager : synchronisation via compte Google. Firefox (120+) : supporte WebAuthn mais sans gestionnaire de passkeys natif — délègue aux gestionnaires tiers (1Password, Bitwarden). Edge : synchronisation via compte Microsoft et Windows Hello.
Les gestionnaires de mots de passe tiers (1Password, Bitwarden, Dashlane) supportent tous les passkeys en 2026. C’est important pour les utilisateurs qui veulent rester indépendants de l’écosystème Apple/Google/Microsoft. Bitwarden étant open source et self-hostable est particulièrement intéressant pour les entreprises soucieuses de souveraineté. 1Password propose une intégration poussée avec les workflows d’équipe.
Le seul angle mort notable : les environnements d’entreprise avec des navigateurs verrouillés en versions anciennes (IE11 legacy, Chrome ESR très conservateur). Pour ces environnements, les FIDO2 hardware keys (YubiKey, Google Titan) restent la solution — elles n’ont pas besoin du mécanisme de synchronisation cloud et sont supportées par CTAP2 depuis plus longtemps que les passkeys synced. Pour un déploiement enterprise, prévoyez une période de coexistence de 12 à 24 mois.
Migration d’un système de mots de passe vers les passkeys
La migration vers les passkeys ne se fait pas en one-shot — c’est un processus de transition qui respecte les utilisateurs existants. L’approche recommandée en 2026 est le ‘progressive enrollment’ : à chaque connexion réussie par mot de passe, proposer à l’utilisateur d’enregistrer une passkey. Un bandeau non intrusif avec un message clair (‘Activez la connexion en une touche avec votre empreinte’) convainc progressivement les utilisateurs sans les forcer.
La mesure du succès de la migration passe par deux métriques principales : le taux d’adoption des passkeys (% d’utilisateurs actifs qui ont enregistré au moins une passkey) et le taux d’authentification par passkey (% des connexions qui utilisent une passkey vs mot de passe). Ces métriques permettent de fixer des jalons progressifs — 25 % d’adoption à 3 mois, 60 % à 6 mois — et d’identifier les segments d’utilisateurs qui ont besoin d’accompagnement supplémentaire.
La suppression définitive des mots de passe (passkey-only) est l’objectif final mais doit être précédée par une longue période de cohabitation. GitHub l’a annoncé pour 2026 pour certains types de comptes. Pour une application B2C classique, viser 18 à 24 mois de cohabitation avant d’envisager de rendre les passkeys obligatoires. Pour les comptes B2B/enterprise avec des contraintes de conformité, coordonnez avec les DSI des clients en amont — ils ont souvent leurs propres politiques de gestion des credentials.
Passkeys dans l’écosystème WordPress
Pour WordPress, plusieurs plugins implémentent WebAuthn/Passkeys en 2026. WP WebAuthn (plugin indépendant) et la fonctionnalité expérimentale de Passkeys dans Jetpack by Automattic sont les deux options les plus matures. L’intégration se fait au niveau du formulaire de connexion wp-login.php via le filtre login_form et les hooks authenticate, permettant aux utilisateurs d’ajouter une passkey comme méthode d’authentification alternative à leur mot de passe.
Pour les développeurs de thèmes et plugins qui gèrent leur propre système d’authentification (membership plugins, communautés fermées), la bibliothèque PHP web-auth/webauthn-lib est la référence côté serveur. Elle gère tous les aspects du protocole (vérification des attestations, gestion des counters, support des différents types d’authenticateurs) et s’intègre dans n’importe quel framework PHP moderne.
L’implémentation de passkeys sur un site WordPress existant avec une base d’utilisateurs établie nécessite une attention particulière à la communication. Prévenez vos utilisateurs en amont, publiez une FAQ claire sur la nouveauté, et assurez-vous que le support peut guider les utilisateurs qui rencontrent des difficultés. Les utilisateurs plus âgés ou moins technophiles peuvent trouver le concept de passkey déstabilisant initialement — la clé est de communiquer sur le bénéfice concret (‘plus besoin de retenir un mot de passe’) plutôt que sur le mécanisme technique.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.