ReportedIP Hive 2.1.36 — Prise en charge officielle de YubiKey et des Hardware Security Keys
ReportedIP Hive 2.1.36 fait des Hardware Security Keys un deuxième facteur d’authentification officiel et à part entière. Une YubiKey — ou toute autre clé FIDO2 ou Passkey d’accès à une plateforme — permet désormais d’effectuer une procédure WebAuthn complète sur les trois interfaces de connexion (wp-login, la vitrine WooCommerce et la page de réinitialisation du mot de passe), grâce à un gestionnaire de clés multiples, à la détection automatique du modèle de clé et aux alertes en cas de clé clonée.
Cette version regroupe les phases de développement 2.1.33 à 2.1.35 en une seule mise à jour. Vous pouvez la télécharger via « Plugins → Vérifier les mises à jour » ou depuis la page des versions sur GitHub Releases ; si vous avez manqué la série de mises à jour consacrées au renforcement du pare-feu qui l’a précédée, l’article sur la version 2.1.21 aborde ce sujet.
Quelles sont les nouveautés depuis la version 2.1.21 de Hive ?
Onze versions ont été publiées entre la 2.1.23 (09/07/2026) et la 2.1.36 (05/08/2026). Le fil conducteur : une application plus stricte des règles avec moins d’erreurs dues à des négligences, une version apportant des gains de performances substantiels, et enfin le cap franchi avec la clé matérielle.
| Version | Modification du titre |
|---|---|
| 2.1.23 | La règle WAF par défaut bloque la sonde PHPUnit eval-stdin.php (CVE-2017-9841) sur tous les plans ; les utilisateurs qui ont épuisé le délai de grâce de l’authentification à deux facteurs (2FA) sont redirigés vers une inscription obligatoire au lieu d’être bloqués. |
| 2.1.24 | Une soumission en double du Login de sécurité de la 2FA ne redirige plus les utilisateurs correctement authentifiés vers une page indiquant que la « session a expiré ». |
| 2.1.25 | Deux règles de base ciblent la classe de confusion des routes REST par lots du cœur de WordPress ; les corps de requête sont comparés à la fois sous leur forme brute et après décodage, ce qui permet de combler une faille permettant de contourner le Payload encodé. |
| 2.1.26 | Les signalements de robots d’indexation sont recoupés avec les données Reverse DNS confirmées en amont et les plages d’adresses IP officielles ; un mécanisme de protection central empêche tout capteur de bloquer automatiquement un Googlebot vérifié ; les sous-sites Multisite lisent à nouveau les tables appropriées. |
| 2.1.27 | Un agent utilisateur falsifié « Jetpack by WordPress.com » ne protège plus contre le blocage automatique en cas d’attaques par Brute Force lors du Login ; l’option « Faire confiance à cet appareil » reste active même après des tentatives infructueuses. |
| 2.1.28 | Un incident affectant la réputation de la communauté entraîne désormais un blocage de 24 heures qui s’applique à l’ensemble du site, et non plus uniquement au formulaire de Login ; la version minimale requise de WordPress a été portée à 5.9. |
| 2.1.29 | Le nouveau commutateur « Garder les pages d’archives des auteurs publiques » permet de distinguer la véritable fuite d’User Enumeration (?author=N) des liens d’archives inoffensifs. |
| 2.1.30 | Le système de protection pré-WordPress applique des blocages d’adresses IP avant le chargement de WordPress et enregistre chaque requête dans un fichier de file d’attente — Extended Protection apparaît enfin dans les journaux et dans la procédure d’escalade. |
| 2.1.31 | La Block Escalation prend en compte le volume des attaques (une rafale de 60 violations permet de sauter des échelons) ; le serveur ne peut plus bloquer automatiquement sa propre adresse IP en cas de préchargement du cache et de boucles cron. |
| 2.1.32 | Amélioration des performances : passage de 36 à 11 requêtes de plugins par requête anonyme ; les réponses de la Blocklist proviennent désormais d’un en-tête de 8 Ko au lieu d’une lecture de fichier de 1 Mo ; temps de réponse total (TTFB) du Dashboard passé de 920 ms à 278 ms sur une table de journaux de 500 000 lignes (schéma v13) ; Les blocages par plage CIDR sont à nouveau appliqués par la couche WordPress. |
| 2.1.36 | Prise en charge officielle de la YubiKey et des Hardware Security Keys, ainsi que refonte de la section « 2FA » du profil (regroupant les versions 2.1.33 à 2.1.35). |
Les Hardware Security Keys constituent désormais un deuxième facteur d’authentification à part entière
Hive prend en charge WebAuthn depuis la version 1.4.0, mais il fallait reconnaître que cette prise en charge était davantage de niveau « Passkey » que de niveau « clé matérielle » : le défi WooCommerce affichait un onglet « Passkey » dont le panneau n’existait pas, et la page de réinitialisation du mot de passe proposait WebAuthn sans charger le moindre script de cérémonie. La version 2.1.36 comble cette lacune. Les trois interfaces de vérification — la page interstitielle wp-login, la page de vérification de la boutique WooCommerce et la page de réinitialisation du mot de passe — affichent désormais un panneau WebAuthn commun (templates/partials/webauthn-challenge-panel.php) et effectuent une procédure d’authentification complète.
Les paramètres de la cérémonie sont adaptés au matériel réel. Le délai d’expiration est porté de 60 à 120 secondes (contre la valeur par défaut de 60 secondes de WebAuthn) (CEREMONY_TIMEOUT_MS, class-two-factor-webauthn.php), car les interactions NFC sur les téléphones nécessitent généralement un délai supplémentaire. Lorsque libsodium est disponible, Ed25519 (EdDSA, COSE −8) est proposé avant ES256 et RS256 et vérifié côté serveur — c’est l’algorithme privilégié par le micrologiciel 5.2.3+ de la YubiKey. Et userVerification la valeur par défaut est discouraged, conformément aux recommandations de Yubico concernant la distinction entre « présence de l’utilisateur » et « vérification de l’utilisateur », de sorte qu’une nouvelle clé ne surprenne jamais l’utilisateur avec une invite de code PIN FIDO2 lors d’un Login à deux facteurs. Les opérateurs souhaitant une vérification par code PIN ou biométrique peuvent renforcer la politique via le reportedip_hive_webauthn_user_verification filtre — et la politique ainsi renforcée est alors appliquée côté serveur, et non pas simplement demandée côté client.
Autre choix délibéré : l’inscription nécessite désormais residentKey: 'discouraged'. L’enregistrement d’une YubiKey comme deuxième facteur d’authentification WordPress ne consomme plus l’un des emplacements limités réservés aux identifiants détectables de la clé (25 sur la plupart des firmwares de la série 5, 100 à partir du firmware 5.7) — l’identifiant est désormais stocké côté serveur. Les identifiants détectables existants continuent de fonctionner.
Un gestionnaire de clés de sécurité est associé au profil utilisateur
Chaque utilisateur dispose désormais d’un gestionnaire « Clés de sécurité et Passkeys » dans son profil : il peut enregistrer plusieurs clés (une principale et une de secours), les nommer et les renommer, les supprimer individuellement, et consulter la date d’ajout et de dernière utilisation de chaque clé. Les boutons d’enregistrement comportent des indications WebAuthn : « Clé de sécurité (USB / NFC) » correspond à authenticatorAttachment: cross-platform, « Cet appareil » à platform — ce qui permet à Chrome et Edge d’ouvrir directement la boîte de dialogue appropriée au lieu de poser deux fois la question. La suppression de la dernière clé désactive la méthode via la procédure normale de désactivation, jamais de manière silencieuse.
Le plugin vous indique quel modèle de clé a été enregistré
La demande d’enregistrement nécessite une attestation directe, vérifie les signatures d’attestation intégrées, extrait l’AAGUID et le compare à un registre regroupant 91 modèles d’authentificateurs — 81 entrées de matériel Yubico ainsi que les principales plateformes de Passkeys (Windows Hello, Trousseau iCloud, Gestionnaire de mots de passe Google, 1Password et autres), provenant du service de métadonnées de la FIDO Alliance. Le modèle détecté (« YubiKey série 5 avec NFC », « Windows Hello ») apparaît sous le nom de la clé. L’ensemble du processus est en lecture seule et fonctionne selon le principe « fail-open » : une attestation manquante ou invérifiable ne bloque jamais un enregistrement, conformément aux recommandations de Yubico selon lesquelles l’attestation doit informer et non constituer un obstacle.
Les clés dupliquées sont détectées et signalées par e-mail
Les authentificateurs tiennent à jour un compteur de signatures qui doit incrémenter à chaque assertion. Une assertion dont le compteur n’incrémente pas est le signe caractéristique d’un authentificateur cloné ou réinitialisé ; Hive la rejette donc désormais, enregistre 2fa_webauthn_counter_regression avec un niveau de gravité élevé et envoie un e-mail au propriétaire du compte — quel que soit le forfait, avec une limite d’un e-mail par identifiant et par heure. Les Passkeys de la plateforme sans compteur (qui indiquent légitimement zéro) continuent de fonctionner. Les assertions sans indicateur de présence de l’utilisateur sont rejetées conformément à la section 7.2 de la norme WebAuthn. Les enregistrements et suppressions de clés déclenchent leurs propres e-mails de notification sur le Business plan.
La section « 2FA » du profil a été remaniée pour les utilisateurs finaux
L’ancienne section « Profil » partait du principe que vous saviez ce que signifiait « TOTP ». La nouvelle version utilise des fiches du système de conception, avec une introduction rédigée en langage simple et une ligne par méthode de connexion — Authenticator App, Passkey / clé de sécurité, code par e-mail, SMS — chacune comportant une description accessible à tous, un indicateur « Actif/Par défaut » et des actions intégrées. Trois changements ont été apportés en arrière-plan :
- Il est possible d’ajouter des méthodes à tout moment, et pas seulement lorsque la 2FA est encore désactivée ; de plus, toutes les interfaces d’inscription (profil, assistant d’intégration, WP-CLI, gestionnaire de clés) passent par un chemin d’activation commun.
- La méthode de connexion par défaut peut être choisie par l’utilisateur. Chaque ligne correspondant à une méthode active propose l’option « Définir comme méthode par défaut » ; le choix est demandé dès la première tentative de Login. En arrière-plan, il s’agit d’un nouveau
set_primary_methodEndpoint AJAX qui délègue àTwo_Factor::set_user_method(), qui rejette toute méthode que l’utilisateur n’a pas effectivement activée. - La gestion des SMS a été intégrée au profil. Il est désormais possible d’y configurer ou de modifier un numéro ; un numéro modifié ne remplace le numéro vérifié qu’après confirmation d’un code par le nouveau numéro — une faute de frappe ne peut donc plus compromettre le bon fonctionnement du système.
Il est désormais possible de supprimer chaque méthode une par une, avec un avertissement clair indiquant que la suppression de la dernière désactiverait complètement le 2FA. Les nouvelles installations autorisent les quatre méthodes par défaut (totp, email, webauthn, sms — le SMS devient utilisable dès qu’un forfait prenant en charge la fonction de relais est activé) ; les sites existants conservent la sélection enregistrée. De plus, l’ajout d’une deuxième méthode ne remplace plus la méthode par défaut de l’utilisateur et ne régénère plus silencieusement les Recovery Codes existants, deux actions que l’ancien Endpoint de confirmation TOTP effectuait auparavant.
Ce qui reste gratuit, et ce qui nécessite un abonnement Business
Une clé de sécurité ou un Passkey par compte est offert gratuitement dans toutes les formules — inscription, Login sur les trois interfaces d’authentification, renommage et suppression, ainsi que l’e-mail d’alerte en cas de clé clonée inclus. La formule Business plan ajoute des fonctionnalités avancées : plusieurs clés par compte, la détection automatique du modèle via attestation, ainsi que les alertes par e-mail relatives au cycle de vie des clés. Cette distinction est appliquée côté serveur au niveau des Endpoints d’inscription (webauthn_advanced dans le tableau des fonctionnalités) ; les inscriptions au Free tier demandent attestation: 'none' , de sorte qu’aucune demande de consentement ne s’affiche jamais dans le navigateur pour une fonctionnalité non incluse dans le niveau d’abonnement. Les détails des formules sont disponibles sur la page des tarifs.
Si vous souhaitez en savoir plus sur les liens entre WebAuthn, les Passkeys et les clés matérielles, le guide de Login par Passkey explique ces concepts ; pour en savoir plus sur la clé spécifique que nous développons et testons, consultez la fiche technique de la YubiKey 5C NFC.
Correctifs de sécurité fournis avec
La prise en charge officielle des clés matérielles a nécessité un audit complet du parcours WebAuthn, qui a donné lieu à plusieurs corrections. Le processus de réinitialisation du mot de passe lie désormais le navigateur à l’identité réinitialisée via un jeton à durée de vie limitée généré par le serveur — et jamais via des paramètres d’URL, qui peuvent faire l’objet de fuites via les référents et les journaux. Les endpoints AJAX de Login WebAuthn sont soumis au même système de verrouillage par adresse IP que le formulaire de défi, ce qui empêche tout contournement de la Rate Limit, et les options d’inscription sont limitées par utilisateur. Le décodeur CBOR autonome rejette les entrées tronquées, de longueur indéfinie, balisées et de type float en renvoyant des messages d’erreur clairs et en appliquant une limite de profondeur d’imbrication ; le chemin COSE sur EC2 vérifie la courbe P-256 avant utilisation.
Deux corrections visant à améliorer l’expérience utilisateur méritent d’être soulignées. Le fait de toucher une YubiKey en dehors d’une session active ne génère plus d’erreurs prêtant à confusion : la saisie d’un code OTP Yubico (la longue chaîne de caractères en minuscules émise par une clé lorsqu’on la touche accidentellement) est détectée et fait l’objet d’une aide à l’utilisateur. De plus, le lancement d’une configuration TOTP ne remplace plus silencieusement le secret d’un authentificateur déjà confirmé ; toute reconfiguration nécessite désormais de cliquer explicitement sur « Configurer à nouveau ». En dehors du sous-système 2FA, la synchronisation « drop-in » du WAF vérifie désormais l’accessibilité en écriture avant chaque écriture de garde, de Blocklist et de directive, et passe en mode « fail-open » au lieu d’afficher des avertissements PHP qui interrompaient les redirections d’administration avec le message « en-têtes déjà envoyés » sur les systèmes de fichiers en lecture seule.
Un renforcement des contrôles et moins de bruit à l’approche de cet endroit
La série de mises à jour 2.1.23–2.1.32 mérite une mention particulière, car plusieurs de ces modifications affectent le fonctionnement quotidien. Depuis les versions 2.1.26/2.1.27, une déclaration de robot d’indexation dans l’agent utilisateur n’a plus aucune valeur en soi : chaque déclaration est recoupée avec le Reverse DNS confirmé en amont et les plages d’adresses IP officielles ; un système de contrôle central n’exempte des décisions de blocage automatique que les robots d’indexation vérifiés ; et les événements impliquant des identifiants, tels que les tentatives de Login infructueuses, contournent entièrement l’Allowlist des bots — les véritables robots d’indexation ne soumettent jamais d’identifiants. Depuis la version 2.1.31, le serveur ne peut plus non plus se bloquer lui-même : les robots d’indexation de préchargement du cache, les boucles WP-Cron et les auto-requêtes REST proviennent de l’adresse publique du site lui-même, et un site Multisite en production avait automatiquement bloqué sa propre adresse IPv6 pendant sept jours pour « abus de la REST API ». Le pipeline automatique est désormais désactivé pour les adresses propres au serveur et une mise à niveau lève les auto-blocages existants.
Les mesures de sécurité ont été renforcées dans le même temps. L’échelle d’escalade tient désormais compte du volume : un attaquant qui déclenche soixante violations de règles en dix secondes saute des échelons, au lieu de se voir infliger les mêmes cinq minutes qu’il aurait écopées pour trois violations. Le garde pré-WordPress (Extended Protection) applique des blocages d’IP avant même le chargement de WordPress et enregistre chaque requête bloquée ; ainsi, l’escalade et les signalements de la communauté fonctionnent même pour les requêtes que WordPress ne voit jamais. Et la version 2.1.32 a pris en charge le coût en termes de performances de tout cela : 36 → 11 requêtes de plugin par requête anonyme, une Blocklist qui répond à partir d’un en-tête de 8 Ko au lieu de lire jusqu’à 1 Mo par requête, et un Dashboard de sécurité dont le TTFB est passé de 920 ms à 278 ms sur une table de journaux de 500 000 lignes.
Comment effectuer la mise à jour vers Hive 2.1.36
L’outil de vérification des mises à jour intégré interroge GitHub toutes les 12 heures ; pour récupérer la nouvelle version immédiatement, ouvrez Plugins → Vérifier les mises à jour. La configuration requise reste inchangée depuis la version 2.1.28 : WordPress 5.9+ et PHP 8.1+. Aucune migration manuelle n’est nécessaire : la procédure de mise à jour gère le schéma, et libsodium (fourni avec PHP depuis la version 7.2) est la seule bibliothèque requise pour Ed25519. La prise en charge matérielle est documentée dans la matrice de test WebAuthn du dépôt, qui valide chaque version sur une véritable YubiKey 5C NFC sous Windows, Android, iPhone et macOS.