Une cliente qui gère seule une boutique en ligne nous a demandé, un peu gênée, si elle pouvait « se connecter avec son visage comme sur son téléphone » plutôt que de retenir un mot de passe qu’elle notait systématiquement sur un post-it collé à son écran. La question n’a rien d’anecdotique : les passkeys, portées par le standard WebAuthn, commencent à s’implanter sur WordPress via des extensions dédiées, et elles apportent une amélioration de sécurité réelle, pas seulement un gain de confort.
Contrairement à un mot de passe, qu’il faut transmettre au serveur pour vérification (même haché), une authentification WebAuthn ne fait jamais voyager de secret sur le réseau. Voici comment cela fonctionne concrètement et comment le déployer sur un site WordPress.
Le principe cryptographique derrière une passkey
Lors de l’enregistrement d’une passkey, l’appareil de l’utilisateur (téléphone, ordinateur, clé de sécurité physique) génère une paire de clés cryptographiques propre à ce site précis. La clé privée ne quitte jamais l’appareil, protégée par le déverrouillage biométrique ou le code de l’appareil. Seule la clé publique correspondante est envoyée et stockée côté serveur WordPress.
Lors d’une connexion, le serveur envoie un défi aléatoire (un « challenge ») que l’appareil signe avec sa clé privée après déverrouillage biométrique. Le serveur vérifie cette signature avec la clé publique déjà enregistrée. Un attaquant qui compromettrait la base de données WordPress ne récupérerait donc que des clés publiques, inutilisables pour usurper une identité, contrairement à des mots de passe même hachés qui restent une cible de choix en cas de fuite.
Ce que WordPress ne fait pas nativement
À la date de rédaction de cet article, le cœur de WordPress n’intègre pas nativement de support WebAuthn : l’écran de connexion reste construit autour du couple identifiant/mot de passe, éventuellement complété par un second facteur TOTP via une extension. L’ajout de passkeys nécessite donc une extension tierce qui prend en charge le protocole côté serveur (génération et vérification des défis, stockage des clés publiques) et l’intégration côté navigateur via l’API JavaScript navigator.credentials, la porte d’entrée standard de WebAuthn dans les navigateurs modernes.
Plusieurs extensions du répertoire officiel proposent cette intégration en s’appuyant sur des bibliothèques WebAuthn éprouvées côté serveur PHP, en s’accrochant aux écrans de connexion et de profil natifs de WordPress plutôt qu’en les remplaçant entièrement.
Mettre en place l’enregistrement d’une passkey
Le parcours type, une fois l’extension installée et activée, se déroule ainsi côté écran de profil utilisateur :
- L’utilisateur clique sur « Ajouter une clé d’accès » dans son profil.
- Le navigateur déclenche l’invite native du système d’exploitation (Face ID, empreinte, code de la clé de sécurité).
- La paire de clés est générée localement, la clé publique et un identifiant de l’appareil sont envoyés au serveur pour stockage.
- Un nom lisible est associé à cette clé (« iPhone de Marie », « clé YubiKey bureau ») pour permettre de gérer plusieurs appareils enregistrés.
Le parcours de connexion avec passkey
Sur l’écran de connexion, un bouton « Se connecter avec une clé d’accès » déclenche l’API navigator.credentials.get(), qui interroge les passkeys disponibles sur l’appareil ou synchronisées via le trousseau du système (iCloud Keychain, Google Password Manager selon la plateforme). L’utilisateur confirme via biométrie, et la session s’ouvre sans jamais saisir ni identifiant ni mot de passe, à condition que le navigateur reconnaisse déjà l’adresse du site pour cette clé.
Le mode de secours, un point à ne jamais négliger
La contrepartie des passkeys est leur dépendance à l’appareil physique : un téléphone perdu, cassé ou volé sans sauvegarde du trousseau système peut couper l’accès au compte. Toute mise en place sérieuse doit donc conserver un mode de secours :
- Autoriser plusieurs passkeys enregistrées par compte (téléphone et clé physique de secours, par exemple).
- Conserver le mot de passe classique comme méthode de repli, éventuellement combiné à un second facteur TOTP.
- Documenter une procédure de récupération administrateur pour les cas où un utilisateur perd tous ses moyens d’authentification.
Pour quels comptes cela a-t-il vraiment du sens
Sur les sites que nous gérons, les passkeys trouvent surtout leur intérêt sur les comptes à privilèges élevés (administrateurs, auteurs multiples sur un site éditorial) plutôt que sur des comptes clients d’une boutique, où le parcours d’achat doit rester le plus simple possible et où la majorité des visiteurs ne dispose pas encore d’un trousseau de passkeys correctement configuré sur tous leurs appareils.
Conseil qui nous a évité une mésaventure : toujours tester l’enregistrement d’une seconde passkey avant de désactiver l’ancien mot de passe d’un client. Un appareil de test mal configuré peut donner l’illusion que tout fonctionne alors que seul le navigateur de démonstration reconnaît la clé.
En résumé
Les passkeys apportent une amélioration de sécurité réelle par rapport au mot de passe seul, en supprimant tout secret transmis au serveur lors de la connexion. Leur mise en place sur WordPress passe par une extension tierce en l’absence de support natif, et gagne à être réservée dans un premier temps aux comptes à privilèges, avec un mode de secours toujours disponible pour éviter tout blocage d’accès.
