YubiKey 5C NFC pour la 2FA WordPress : guide technique

La YubiKey 5C NFC est la clé matérielle avec laquelle notre équipe se connecte tous les jours, et depuis Hive 2.1.36 elle est un second facteur officiellement pris en charge sur tout site WordPress équipé du plugin. Ce guide couvre le matériel, la cérémonie WebAuthn qui se joue derrière la connexion, les réglages que Hive écrit, les hooks pour les développeurs et les neuf erreurs que vous rencontrerez vraiment en production.

La photo ci-dessus n’est pas une image de banque : c’est la YubiKey 5C NFC de notre propre poste de développement, l’appareil de référence derrière chaque version de Hive. Tous les numéros de version et valeurs par défaut cités ci-dessous proviennent de Hive 2.1.57, publiée le 15/09/2026.

Qu’est-ce que la YubiKey 5C NFC ?

La YubiKey 5C NFC est un authentificateur matériel fabriqué par Yubico. Elle conserve des clés cryptographiques dans un élément sécurisé, signe les challenges de connexion quand vous la touchez, et n’expose jamais la clé privée à l’ordinateur. Pas de pile, pas d’écran, pas de connexion réseau. Elle se branche en USB-C ou s’approche d’un téléphone compatible NFC, exactement la combinaison dont une administratrice WordPress a besoin : câble au bureau, approche rapide en déplacement.

Connecteurs	USB-C et NFC (approche rapide sous Android et iOS)
Protocoles d’authentification	WebAuthn / FIDO2 (CTAP 1, 2 et 2.1), U2F, carte à puce PIV, Yubico OTP, OATH-HOTP/TOTP, OpenPGP, mots de passe statiques
Capacité en passkeys	25 credentials découvrables ; 100 à partir du firmware 5.7
Algorithmes de signature	ES256, RS256 ; Ed25519 (EdDSA) depuis le firmware 5.2.3
Fabrication	IP68 résistante à l’eau et à la poussière, résistante à l’écrasement, sans pile ni pièce mobile ; fabriquée en Suède

Les spécifications complètes figurent sur la page produit officielle de Yubico ; l’histoire d’Ed25519 commence avec les notes de version du firmware 5.2.3. Une remarque pratique sur la capacité : la limite de 25 ne concerne que les credentials découvrables, c’est-à-dire les passkeys stockées sur la clé elle-même. Un second facteur WordPress configuré via Hive n’occupe aucun de ces emplacements ; le pourquoi est détaillé plus bas.

Pourquoi une clé matérielle bat les codes à usage unique

Tout second facteur fondé sur un code, application d’authentification, e-mail ou SMS, partage une même faiblesse : le code peut être saisi sur la mauvaise page. Un site de phishing qui relaie votre vraie page de connexion retransmet un code TOTP dans sa fenêtre de 30 secondes, et les attaquants automatisent précisément cela avec des boîtes à outils de reverse proxy toutes faites. Une clé FIDO2 est immunisée par construction contre cette classe d’attaque : la signature qu’elle produit est liée à l’origine qui l’a demandée, donc un credential enregistré pour votre vrai domaine ne produit rien d’exploitable sur un domaine sosie. Il n’y a pas de code à voler parce qu’il n’y a pas de code.

Second facteur	Résistant au phishing	Fonctionne hors ligne	Panne typique
Application d’authentification (TOTP)	Non, les codes peuvent être relayés	Oui	Téléphone perdu ou réinitialisé sans sauvegarde
Code par e-mail	Non	Non	Boîte mail compromise ou message retardé
Code par SMS	Non	Non	Échange de carte SIM, échecs de livraison
Clé matérielle (FIDO2)	Oui, signatures liées à l’origine	Oui	Clé perdue sans clé de secours

La réserve honnête tient dans la dernière case : une clé perdue sans solution de repli vous verrouille dehors. La réponse pratique est celle que donne Yubico. Enregistrez deux clés et gardez la seconde hors du bureau. Hive prend cela en charge avec un gestionnaire de clés qui accueille un credential principal et un credential de secours, plus les codes de récupération et toute autre méthode 2FA comme repli. Notre guide de la 2FA sous WordPress compare les quatre méthodes plus en détail.

Comment se déroule vraiment la cérémonie WebAuthn

Comprendre la cérémonie explique la plupart des messages d’erreur que vous verrez un jour, ces 400 mots valent donc la peine. WebAuthn découpe l’authentification en deux cérémonies : l’enregistrement, où la clé crée une nouvelle paire de clés, et l’assertion, où la clé signe un challenge pour prouver qu’elle détient toujours la moitié privée.

L’enregistrement lie une paire de clés à un seul domaine

Lorsque vous enregistrez une clé, le serveur envoie un challenge aléatoire de 32 octets, un identifiant de partie de confiance (le nom d’hôte nu, par exemple example.com) et une liste d’algorithmes de signature acceptés. Le navigateur y ajoute l’origine qu’il affiche, condense l’ensemble dans clientDataJSON et transmet la demande à l’authentificateur. La clé génère une paire de clés neuve limitée à cet identifiant de partie de confiance, garde la clé privée dans l’élément sécurisé et renvoie la clé publique ainsi qu’un identifiant de credential. Le serveur stocke les deux. Aucun secret ne circule jamais sur le réseau, et la même clé produit une paire complètement différente sur chaque site, de sorte que deux sites ne peuvent pas rapprocher leurs utilisateurs via le credential.

L’assertion prouve la possession sans rien révéler

À la connexion, le serveur envoie un nouveau challenge aléatoire et la liste des identifiants de credentials qu’il connaît pour ce compte. La clé signe la concaténation de ses données d’authentificateur et de l’empreinte SHA-256 de clientDataJSON. Le serveur vérifie cette signature avec la clé publique stockée et contrôle quatre points : le challenge correspond à celui qu’il a émis, l’origine figure sur sa liste d’autorisation, l’empreinte de l’identifiant de partie de confiance correspond, et le drapeau de présence utilisateur est levé. La signature ne vaut rien sur un autre domaine, puisque l’origine est comprise dans la charge signée. C’est précisément cette propriété qui fait échouer un proxy de phishing : l’attaquant peut relayer les octets, mais la signature porte son propre domaine et le vrai serveur la rejette.

À quoi sert le contact du doigt

Toucher le disque doré lève le drapeau de présence utilisateur. Cela prouve qu’un humain se trouve physiquement devant la clé, et non un logiciel malveillant qui pilote silencieusement la pile USB. Ce n’est pas une vérification d’identité. La vérification d’identité (le drapeau UV) est une étape distincte qui exige un code PIN FIDO2 ou une empreinte digitale, et Hive ne la demande délibérément pas par défaut. Le raisonnement figure dans la section suivante.

Comment Hive implémente WebAuthn dans WordPress

Hive embarque un vérificateur WebAuthn de niveau 2 autonome dans class-two-factor-webauthn.php (1 325 lignes), sans dépendance Composer. Il analyse les objets d’attestation CBOR et les clés publiques COSE avec l’OpenSSL de la bibliothèque standard, ce qui garde le plugin distribué léger. Le compromis est documenté dans l’en-tête de la classe : il couvre le sous-ensemble nécessaire au second facteur et ne valide pas les chaînes de certificats d’attestation contre le FIDO Metadata Service.

C’est une décision assumée, pas une lacune. L’attestation indique seulement quel modèle de clé a servi. La cérémonie d’enrôlement a de toute façon lieu après une authentification par mot de passe réussie, une chaîne d’attestation vérifiée n’ajoute donc aucune entropie utile à un second facteur. Hive vérifie les déclarations d’attestation packed au mieux de ses moyens et n’en tire qu’une seule chose : l’étiquette du modèle dans le gestionnaire de clés.

Les algorithmes proposés à l’enregistrement

Hive propose trois algorithmes COSE, le plus robuste en tête : Ed25519 (-8), ES256 (-7) et RS256 (-257). Ed25519 n’entre dans la liste que si sodium_crypto_sign_verify_detached() existe sur le serveur, car un credential enregistré aujourd’hui avec un algorithme que le serveur ne saurait pas vérifier demain serait un verrouillage silencieux. À partir de PHP 7.2, libsodium fait partie du cœur, la plupart des hébergeurs remplissent donc la condition. Une YubiKey en firmware 5.2.3 ou plus récent choisit Ed25519 dans cette liste, et vous pouvez le confirmer sur votre propre installation : le credential stocké annonce l’algorithme COSE −8.

Pourquoi userVerification reste sur discouraged

Hive fixe userVerification: 'discouraged' pour les deux cérémonies, la valeur que Yubico recommande pour un usage en pur second facteur. Une YubiKey neuve n’a pas de code PIN FIDO2, et preferred ou required pousserait l’utilisateur dans la création d’un PIN au milieu d’une connexion. Les authentificateurs de plateforme comme Windows Hello ou Touch ID vérifient l’utilisateur de manière intrinsèque quelle que soit cette valeur, rien n’est donc perdu de ce côté. Les sites qui veulent une vérification stricte relèvent la valeur via le filtre reportedip_hive_webauthn_user_verification, et le serveur impose alors le drapeau UV à chaque cérémonie au lieu de faire confiance au client.

Pourquoi l’enrôlement ne consomme pas d’emplacement de passkey

L’enregistrement demande residentKey: 'discouraged'. Un credential découvrable, c’est-à-dire une passkey stockée sur la clé elle-même, occuperait l’un des 25 emplacements de la YubiKey et forcerait la création d’un PIN FIDO2 en pleine configuration, sans le moindre gain pour un second facteur : le flux de connexion fournit toujours allowCredentials, la clé n’a donc jamais à découvrir quoi que ce soit par elle-même. Le credential vit dans les métadonnées utilisateur du site, la clé ne stocke rien, et une seule YubiKey peut donc servir un nombre illimité de sites WordPress. Les credentials enregistrés avant ce changement continuent de fonctionner.

Gestion des challenges et liaison à l’identité

Les challenges font 32 octets aléatoires, tiennent 300 secondes dans un transient et sont supprimés à l’instant où ils sont consommés, une réponse rejouée échoue donc dès la deuxième tentative. Pendant la connexion l’utilisateur n’est pas encore authentifié, ce qui exclut un nonce WordPress classique. Hive lie l’identité via le cookie httpOnly reportedip_2fa_token que le filtre d’authentification pose après la vérification du mot de passe, avec une durée de vie de 900 secondes. Le JavaScript ne lit jamais ce jeton, ce qui le met hors de portée d’une injection de script. Les surfaces dépourvues de ce cookie, en particulier le portail de réinitialisation du mot de passe, reçoivent à la place un jeton de cérémonie à usage unique. Aucun des deux jetons ne remplace la signature : le présenter ne donne accès qu’à la cérémonie.

Les trois surfaces de challenge

Une clé de sécurité fonctionne aux trois endroits où WordPress peut réclamer un second facteur : le challenge de wp-login.php, le challenge WooCommerce côté boutique pour les comptes clients, et le portail de réinitialisation du mot de passe. Ce dernier compte plus qu’il n’y paraît. Un site qui protège la connexion mais laisse la réinitialisation ouverte à un second facteur uniquement par e-mail a déplacé l’attaque au lieu de la supprimer. C’est pourquoi l’option reportedip_hive_2fa_password_reset_excluded_methods y exclut email par défaut.

Configurer une YubiKey sur votre site WordPress avec Hive

La formule gratuite inclut une clé de sécurité ou une passkey par compte, utilisable sur les trois surfaces. La configuration prend environ deux minutes.

Installez ReportedIP Hive (2.1.36 ou plus récent) et activez l’authentification à deux facteurs. Depuis la 2.1.54, cet interrupteur se trouve sur la page de démarrage rapide, et les quatre méthodes sont autorisées par défaut.
Ouvrez votre profil WordPress et repérez la carte Security keys & passkeys.
Nommez d’abord la clé (YubiKey bureau aide davantage que Clé 1 le jour où vous devrez décider quel credential révoquer), puis choisissez Security key (USB / NFC). Ce bouton envoie l’indice security-key, ce qui fait ouvrir à Chrome et Edge la boîte de dialogue matérielle directement, au lieu de proposer d’abord un QR code pour téléphone.
Branchez la clé et touchez le disque doré, ou tenez-la à plat contre le haut de votre téléphone pour le NFC.
Enregistrez une seconde clé en secours, ou générez des codes de récupération comme repli.

Le second bouton de cette carte, This device (Face ID / Windows Hello), envoie l’indice client-device et enrôle l’authentificateur de plateforme à la place. Les deux aboutissent dans la même liste de credentials ; seuls l’étiquette du modèle et le transport diffèrent.

Un détail qui évite un ticket de support : l’enregistrement est limité à dix demandes d’options par utilisateur et par tranche de dix minutes. Tester l’enrôlement en boucle sur un site de préproduction atteint ce plafond, et le message (« Too many registration attempts ») ressemble à un bug quand on ignore la règle.

Quels réglages du site gouvernent les clés de sécurité

La plupart des sites n’y touchent jamais, mais savoir ce qui existe transforme un déploiement d’obligation 2FA en plan plutôt qu’en pari. Tous ces réglages se trouvent sur la page Protection depuis la 2.1.56, et tous peuvent être appliqués à distance via MainWP ou le transport de flotte cloud.

Option	Valeur par défaut	Effet
`2fa_allowed_methods`	totp, email, webauthn, sms	Les méthodes que les utilisateurs peuvent configurer. Une méthode retirée ici est refusée côté serveur à l’enrôlement, si bien qu’une clé ne peut pas être enregistrée pendant que la méthode est désactivée pour se mettre à fonctionner en silence dès sa réactivation.
`2fa_enforce_roles`	administrator	Les rôles qui doivent disposer d’un second facteur.
`2fa_enforce_grace_days`	7	Nombre de jours pendant lesquels un utilisateur concerné peut se connecter avant que la configuration devienne obligatoire.
`2fa_max_skips`	3	Combien de fois l’invitation à configurer peut être repoussée une fois le délai écoulé.
`2fa_enforce_action`	enroll	Ce qui se passe quand le délai et les reports sont épuisés. Réglé sur `lockout`, la connexion est refusée, sauf pour les administrateurs et super-administrateurs, qui ne sont jamais verrouillés afin qu’un site ne se retrouve jamais sans compte utilisable.
`2fa_trusted_device_days`	30	Combien de temps un appareil reste de confiance avant que le second facteur soit redemandé.
`2fa_ip_allowlist`	vide	IP ou blocs CIDR qui sautent le challenge (IPv4 et IPv6). Utile pour une plage de bureau, risqué pour tout ce qui est dynamique.
`2fa_enforce_super_admins`	true	Les super-administrateurs multisite ont toujours besoin d’un second facteur.

Les échecs de vérification montent par paliers fixes et par IP, partagés par toutes les méthodes 2FA : 3 échecs coûtent 30 secondes, 5 coûtent 5 minutes, 10 coûtent 30 minutes, 15 coûtent une heure. Les points de terminaison WebAuthn consultent ce palier avant d’émettre un challenge, si bien que des tentatives scriptées contre le point d’assertion butent sur le même mur que la devinette de codes automatisée.

Ce que détecte le compteur de signatures

Chaque authentificateur tient un compteur qu’il incrémente à chaque assertion et inclut dans les données signées. Le serveur retient la dernière valeur vue. Si une nouvelle assertion arrive avec un compteur qui n’a pas avancé, soit la clé a été clonée, soit son état a été restauré à l’identique. Hive refuse cette connexion, écrit un événement 2fa_webauthn_counter_regression de gravité high avec l’identifiant utilisateur, l’identifiant du credential et les deux valeurs de compteur, et déclenche un hook d’action qui envoie un courriel au titulaire du compte. Cet avertissement est inclus dans toutes les formules.

Une exception est prévue : beaucoup de passkeys de plateforme (trousseau iCloud, Google Password Manager) annoncent par conception un compteur constamment à zéro, puisqu’un credential synchronisé n’a pas d’appareil unique sur lequel compter. Hive traite un zéro stocké et un zéro annoncé comme normaux et ne signale qu’une vraie régression. Cloner une YubiKey n’est pas une attaque réaliste, la clé privée ne quitte jamais l’élément sécurisé, mais le contrôle ne coûte rien et attrape le cas où la sauvegarde d’un authentificateur émulé est restaurée.

Prévoir la clé que vous finirez par perdre

Perdre une clé est la seule panne réaliste de ce dispositif, prévoyez-la donc avant d’en avoir besoin. Quatre solutions de repli existent, par confort décroissant.

Une seconde clé enregistrée. La voie confortable, et la raison pour laquelle la formule Business autorise plusieurs credentials par compte. Rangez la clé de secours dans un lieu physiquement séparé de la première.
Les codes de récupération. Des codes à usage unique produits lors de la configuration. Imprimez-les ou rangez-les dans un gestionnaire de mots de passe, jamais dans le profil de navigateur que vous protégez.
Une seconde méthode. TOTP en facteur parallèle ne coûte rien et survit à une clé perdue. Elle résiste moins bien au phishing, c’est un compromis que vous acceptez en connaissance de cause.
WP-CLI. Une administratrice serveur lance wp reportedip 2fa reset <user_id>, ce qui retire toutes les données 2FA du compte et inscrit un avertissement dans le journal d’activité, de sorte que la remise à zéro reste vérifiable.

Hive refuse un verrouillage auto-infligé bien précis : supprimer votre dernière clé restante quand WebAuthn est votre seule méthode active et que votre rôle est soumis à l’obligation. La suppression est rejetée avec un message qui vous demande de configurer d’abord une autre méthode. En dehors de ce cas, retirer un credential l’invalide immédiatement, et c’est exactement ce que vous faites à la seconde où une clé disparaît.

Multisite, sous-domaines et préproduction : là où l’identifiant de partie de confiance mord

L’identifiant de partie de confiance dérive de l’hôte de home_url(). Un credential n’est valable que pour cet identifiant, ce qui produit trois situations qu’il vaut mieux connaître avant un déploiement qu’après.

Multisite en sous-domaines. Une clé enregistrée sur shop.example.com ne fonctionne pas sur blog.example.com. Le filtre reportedip_hive_webauthn_rp_id permet à une administratrice réseau de renvoyer le domaine parent enregistrable (example.com) pour qu’un seul enrôlement couvre tout le réseau. Réglez-le une fois, avant le déploiement : changer l’identifiant plus tard rend orphelin chaque credential enregistré sous l’ancienne valeur.
Tableau de bord sur un autre hôte. Les installations où site_url() et home_url() diffèrent sont traitées automatiquement, car les deux hôtes rejoignent la liste des origines acceptées. Le filtre reportedip_hive_webauthn_allowed_origins couvre les cas plus exotiques.
Copies de préproduction. Une base clonée depuis la production porte des credentials de production dont l’identifiant ne correspond pas à l’hôte de préproduction. L’assertion échoue sur l’origine ou sur l’identifiant. C’est le comportement correct, pas un bug. Enregistrez une clé distincte en préproduction, ou gardez-y une autre méthode 2FA active.

Une contrainte voisine fait trébucher les installations locales : WebAuthn exige un contexte sécurisé. HTTPS, ou http://localhost. Un site de préproduction en HTTP simple sur une adresse de réseau local n’affichera jamais la boîte de dialogue de la clé, et le navigateur signale cela comme une erreur de sécurité plutôt que comme une fonction absente.

Neuf erreurs que vous verrez vraiment, et ce qu’elles signifient

Les navigateurs restent volontairement vagues sur les erreurs WebAuthn, car des messages détaillés révéleraient des informations sur les credentials enregistrés. Hive traduit les exceptions du navigateur en textes exploitables, et le tableau ci-dessous les ramène à leurs causes.

Message ou exception	Cause	Solution
`NotAllowedError` (« request timed out or was cancelled »)	La cérémonie a dépassé 120 secondes, la boîte de dialogue a été fermée, ou la clé n’a jamais été touchée. Le cas NFC le plus fréquent : la clé a été tenue au mauvais endroit du téléphone.	Réessayer, et sur un téléphone tenir la clé à plat contre l’antenne, en général dans le tiers supérieur du dos.
`SecurityError`	L’origine de la page ne correspond pas à l’identifiant de partie de confiance du credential. Clone de préproduction, sous-domaine différent, ou site accessible à la fois en www et sans www.	Se connecter sur l’hôte canonique, ou régler le filtre d’identifiant avant le déploiement.
`InvalidStateError` à l’enregistrement	Cette clé est déjà enrôlée sur ce compte. Le serveur transmet les identifiants existants dans `excludeCredentials` et l’authentificateur refuse le doublon.	Rien à corriger. Utilisez la clé déjà enregistrée, ou enregistrez-en une autre.
`AbortError`	Une autre requête WebAuthn a pris la main, ou la page a changé en pleine cérémonie.	Réessayer sur une page de challenge fraîchement chargée.
« Challenge expired, please start again »	Plus de 300 secondes se sont écoulées entre l’ouverture de la boîte de dialogue et la réponse.	Relancer la cérémonie.
« Signature counter anomaly »	Le compteur n’a pas avancé. Authentificateur cloné ou restauré en arrière, ou image d’émulateur remise en place.	À traiter comme un incident : révoquer le credential, enregistrer une nouvelle clé, consulter le journal d’activité.
« Too many registration attempts »	Dix cérémonies d’enrôlement lancées en dix minutes.	Attendre quelques minutes. C’est attendu pendant les tests.
« Security keys are not available on this site »	La méthode WebAuthn est désactivée dans la liste des méthodes autorisées.	La réactiver sur la page Protection.
« Multiple security keys per account require the Business plan »	Un second credential a été tenté sur une formule qui en inclut une.	Utiliser des codes de récupération ou une seconde méthode en secours, ou comparer les formules sur la page des tarifs.

Un symptôme n’est pas une erreur du tout : une suite de caractères aléatoires qui apparaît dans le champ du mot de passe, commençant en général par cccc. C’est du Yubico OTP. La clé a tapé un mot de passe à usage unique parce qu’elle a été touchée alors qu’un champ texte avait le focus, en dehors de toute cérémonie WebAuthn. Videz le champ et lancez la cérémonie depuis son propre bouton.

Le NFC sur téléphone : ce qui marche et ce qui ne marche pas

Le NFC est la partie du dispositif qui sème le plus de confusion, parce que l’échec se manifeste par un silence et non par un message. Trois éléments décident si l’approche fonctionne.

La position. L’antenne n’est pas au milieu du téléphone. Sur la plupart des appareils Android elle se situe dans le tiers supérieur du dos, sur les iPhone tout en haut. Tenez la clé à plat et immobile une seconde ou deux plutôt que de l’agiter.
Les coques. Le plastique fin ne gêne pas. Les plaques métalliques pour supports magnétiques de voiture, les coques-batteries épaisses et certains étuis portefeuille bloquent complètement le champ.
Le temps. Réveiller le téléphone, trouver la clé et la positionner prend régulièrement plus que les 60 secondes prévues par défaut dans WebAuthn. Hive porte le délai de cérémonie à 120 secondes précisément pour cette raison, et cette valeur est une constante dans la classe WebAuthn, pas un réglage.

Sous iOS, le navigateur affiche une fenêtre système qui vous demande d’approcher la clé du haut de l’appareil avant que la cérémonie démarre. Sous Android l’invite varie selon la version de Chrome, et si le NFC est désactivé dans les réglages système, le navigateur propose silencieusement le parcours par QR code sur un second appareil. Activer le NFC dans les réglages rapides est la solution à laquelle personne ne pense.

Hooks, filtres et WP-CLI pour les développeurs

L’implémentation WebAuthn expose trois filtres et trois hooks d’action. Les filtres façonnent la cérémonie, les actions vous permettent de brancher les événements de cycle de vie des clés sur votre propre audit ou vos alertes.

Hook	Type	Usage
`reportedip_hive_webauthn_rp_id`	Filtre	Renvoie le domaine parent enregistrable pour un multisite en sous-domaines. À régler une fois, avant le déploiement.
`reportedip_hive_webauthn_allowed_origins`	Filtre	Ajoute des origines acceptées pour les installations à domaines mappés ou à hôtes séparés.
`reportedip_hive_webauthn_user_verification`	Filtre	Relève la valeur à `preferred` ou `required`. Le drapeau UV est alors imposé côté serveur à chaque cérémonie.
`reportedip_hive_2fa_webauthn_key_registered`	Action	Se déclenche avec l’identifiant utilisateur et le nom de la clé après le stockage d’un credential.
`reportedip_hive_2fa_webauthn_key_removed`	Action	Se déclenche avec l’identifiant utilisateur et le nom de la clé après la suppression d’un credential.
`reportedip_hive_2fa_webauthn_counter_regression`	Action	Se déclenche avec l’identifiant utilisateur, l’identifiant du credential et le nom de la clé quand une assertion est refusée pour compteur figé.

En ligne de commande, wp reportedip 2fa status liste chaque utilisateur avec ses méthodes configurées et indique si l’obligation s’applique, c’est le moyen le plus rapide d’auditer un déploiement. wp reportedip 2fa enforce --role=editor ajoute un rôle à la liste des rôles soumis, et --remove l’en retire. La commande qui mérite un avertissement est wp reportedip 2fa enable --method=webauthn : activer la méthode pour un utilisateur qui n’a enregistré aucun credential est un verrouillage, pas une configuration, la commande refuse donc tant que vous ne passez pas --force.

Quelles clés de sécurité fonctionnent avec WordPress et Hive ?

Tout authentificateur FIDO2/WebAuthn fonctionne. La série YubiKey 5 est celle avec laquelle nous testons, et le même parcours d’enrôlement accepte les modèles Security Key by Yubico, les clés FIDO2 d’autres fabricants et les passkeys de plateforme comme Windows Hello, le trousseau iCloud, Google Password Manager, 1Password ou Bitwarden.

Dans la formule Business, le gestionnaire de clés nomme le matériel au lieu d’afficher une étiquette générique. Cela vient d’un registre AAGUID statique livré avec le plugin : 90 identifiants d’authentificateurs associés à 32 noms de modèles, les entrées Yubico tirées du FIDO Alliance Metadata Service, les fournisseurs de plateforme de la liste AAGUID communautaire. La recherche sert uniquement à l’affichage et n’alimente jamais une décision de politique, un AAGUID inconnu retombe donc simplement sur l’étiquette générique. Il n’y a ni requête à l’exécution ni tâche cron derrière, la liste est rafraîchie quand du nouveau matériel sort.

Si vous utilisez déjà des passkeys, le guide de la connexion par passkey explique comment les deux se rejoignent. En résumé : une clé matérielle est une passkey que vous tenez en main, que vous ne prêtez à personne et que vous pouvez laisser dans un coffre.

Comment nous utilisons et testons la YubiKey 5C NFC

Nous n’avons pas choisi ce modèle pour l’article. L’article existe parce que nous utilisons ce modèle. La YubiKey 5C NFC protège nos propres comptes, et cette même clé physique est le verrou de publication de la prise en charge WebAuthn de Hive : aucune version touchant au chemin 2FA ne sort tant que la clé n’a pas réussi l’enrôlement et la connexion sur un site de préproduction à travers cinq combinaisons de plateforme et de transport. Windows 11 avec Chrome et avec Edge en USB-C, Android Chrome et iPhone Safari en NFC, et macOS Safari en USB-C. La matrice vérifie aussi qu’une seconde clé s’enregistre proprement, qu’une clé étrangère est refusée, et qu’une cérémonie annulée puis relancée repart sans rechargement de page.

La couverture automatisée tourne en intégration continue via Playwright et l’authentificateur virtuel de Chromium à chaque build. Elle attrape vite et à bas coût les régressions de protocole, et elle est aveugle à tout ce qui est physique : le positionnement NFC, les vrais compteurs de signatures, la sensation d’un délai de 120 secondes, et le cas du contact accidentel où une YubiKey tape son mot de passe à usage unique dans un formulaire parce que quelqu’un l’a effleurée en pleine session. Cet écart entre émulation et matériel explique pourquoi une clé physique reste dans le processus de publication.

Un plan de déploiement pour une équipe

Faire passer toute une équipe éditoriale aux clés matérielles échoue de façon prévisible. Cet ordre évite l’essentiel des écueils.

Achetez deux clés par compte privilégié. Un déploiement avec une seule clé par personne crée une file d’attente au support trois mois plus tard, quand la première passe au lave-linge.
Enrôlez votre propre compte en premier et déconnectez-vous entièrement. Vérifiez la connexion dans une fenêtre privée avant de toucher au compte de quelqu’un d’autre.
Imposez un rôle à la fois, en commençant par les administrateurs. Le délai par défaut de 7 jours plus 3 reports donne aux gens deux vraies occasions de s’enrôler sans ticket au support.
Gardez une méthode sans WebAuthn active pendant le déploiement. TOTP ne coûte rien et évite le seul scénario qui abîme la confiance dans tout le projet : un rédacteur verrouillé dehors à l’heure du bouclage.
Auditez avec wp reportedip 2fa status avant de passer 2fa_enforce_action à lockout. La commande montre à qui il manque encore une méthode.
Notez où se trouvent les clés de secours. Une clé de secours introuvable n’est pas une sauvegarde.

Questions fréquentes

Que se passe-t-il si je perds ma YubiKey ?

Vous vous connectez avec votre solution de secours : une seconde clé enregistrée, des codes de récupération, ou toute autre méthode 2FA active. Retirez ensuite la clé perdue de votre profil, ce qui invalide son credential immédiatement. S’il n’existe aucun repli, une administratrice du site remet la 2FA à zéro avec wp reportedip 2fa reset <user_id>, et cette remise à zéro est inscrite au journal d’activité.

La YubiKey 5C NFC fonctionne-t-elle avec mon téléphone ?

Oui. Sur Android et iPhone, tenez la clé à plat contre l’antenne NFC, en général dans le tiers supérieur du dos ou sur le bord supérieur, quand le navigateur la réclame. Le délai de cérémonie de 120 secondes de Hive existe justement parce que trouver la position prend un instant. Les coques épaisses ou à dos métallique bloquent le champ.

Faut-il une formule payante pour utiliser une YubiKey avec Hive ?

Non. Une clé de sécurité ou une passkey par compte est gratuite dans toutes les formules, connexion sur les trois surfaces comprise, ainsi que le renommage, la suppression et le courriel d’alerte en cas de clé clonée. Business ajoute plusieurs clés par compte, la détection automatique du modèle et les alertes de cycle de vie des clés.

Enrôler un site WordPress consomme-t-il un des 25 emplacements de passkey ?

Non. Hive enregistre un credential non découvrable, la clé ne stocke donc rien et le nombre d’emplacements reste intact. Une YubiKey peut ainsi protéger un nombre illimité de sites WordPress.

Ma clé fonctionnera-t-elle sur une copie de préproduction ?

Pas avec des credentials clonés depuis la production. Un credential est lié à l’identifiant de partie de confiance dérivé de l’hôte du site, un domaine de préproduction le rejette donc pour non-correspondance d’origine ou d’identifiant. Enregistrez-y une clé distincte, ou gardez-y une autre méthode 2FA activée.

Dois-je définir un code PIN FIDO2 ?

Pas pour un usage en second facteur. Hive demande userVerification: 'discouraged', une clé neuve ne déclenche donc jamais la création d’un PIN pendant la connexion. Les sites qui veulent que la clé vérifie elle-même l’utilisateur relèvent la règle via le filtre reportedip_hive_webauthn_user_verification.

Une clé matérielle vaut-elle mieux qu’une passkey dans mon gestionnaire de mots de passe ?

Les deux résistent au phishing. La différence tient à la garde : une passkey synchronisée vaut la sécurité du compte par lequel elle se synchronise, alors que la clé privée d’une clé matérielle ne peut physiquement pas quitter l’appareil. Pour un compte administrateur WordPress, une cible qui mérite une attaque ciblée, nous utilisons des clés matérielles et gardons une passkey synchronisée comme repli de confort.

Puis-je utiliser une seule clé pour plusieurs sites WordPress ?

Oui, et sans limite pratique. Chaque site génère sa propre paire de clés limitée à son propre domaine, et aucune de ces paires n’occupe de stockage sur la clé.

YubiKey 5C NFC pour la 2FA WordPress : installation, coulisses, dépannage