Plugin WordPress — ReportedIP Hive (Full Edition)

ReportedIP Hive est un plugin de sécurité WordPress développé par la communauté. Il transforme chaque site protégé en capteur : lorsqu’un site est attaqué, la « ruche » en tire des enseignements et tous les autres sites peuvent repousser l’attaquant avant même que la première requête n’aboutisse. Threat Intelligence en temps réel, seize Attack Sensors dont un Web Application Firewall, une authentification à deux facteurs (2FA) à quatre méthodes, Progressive Block Escalation et ensembles de règles de pare-feu signés et fournis par le serveur. Open source, publié sous licence GPLv2+ sur GitHub.

Installation

Setup Wizard (10 étapes)

L'assistant s'exécute lors de la première activation et peut être relancé à tout moment depuis les paramètres du plugin. Chaque étape est immédiatement enregistrée côté serveur à chaque navigation (y compris en cliquant sur « Retour »), ce qui vous permet de vous arrêter et de reprendre sans perdre aucun paramètre.

Modes de fonctionnement

Deux modes — basculez entre eux à tout moment sans perdre vos données locales.

Ce dont vous bénéficiez à chaque niveau

Le plugin Hive est entièrement fonctionnel sur la formule Free : protection locale, les seize capteurs, les quatre méthodes d’authentification à deux facteurs (2FA). Les niveaux payants incluent une infrastructure de diffusion gérée (e-mail et SMS) ainsi que des quotas plus élevés pour le Community Network. Consultez la page Tarifs pour une comparaison complète et pour passer à un niveau supérieur.

La formule Business peut faire l'objet de plusieurs réservations. Tous les chiffres indiqués ci-dessus pour la formule Business s'entendent par licence. Réservez la formule Business x2, x5, x10 ou x20 lors du paiement (ou modifiez ce choix ultérieurement dans le portail client Stripe) : le nombre de vérifications/Reports quotidiens, le quota mensuel d’e-mails/SMS pour l’authentification à deux facteurs (2FA) et le nombre de domaines s’adaptent tous en fonction du nombre de licences que vous possédez — par exemple, x5 = 75 domaines et 500 000 vérifications/jour. Une remise sur volume s’applique automatiquement à partir de x2. La formule PRO reste à licence unique ; les chiffres de la formule Enterprise sont illimités (dans le cadre d’une utilisation raisonnable) et ne sont jamais multipliés.

Ordre de consommation des forfaits (PRO et Business) : d’abord le quota mensuel inclus (25 SMS / 500 e-mails pour la version PRO, 75 / 2 500 pour la version Business), puis le solde prépayé du forfait. Une fois ces deux quotas épuisés, l’API renvoie un code HTTP 429 et Hive bascule vers l’authentification locale wp_mail() pour les e-mails (ou les limites strictes pour les SMS) — les autres méthodes de 2FA restent opérationnelles. Les crédits des forfaits n’expirent jamais. Stripe utilise tax_behavior = inclusive pour les forfaits au prix brut (conformes à la PAngV) ; la facturation inversée / OSS est gérée automatiquement par Stripe Tax.

Défense en 6 couches

Hive applique ses vérifications dans l’ordre — chaque couche peut interrompre la requête avant qu’elle n’atteigne la suivante. Les plugins sont init priorité 1 afin que les autres plugins ne s’exécutent pas pour une adresse IP bloquée.

1. Whitelist — les adresses IP et plages CIDR de confiance sont toujours autorisées (votre bureau, les services de surveillance, etc.).
2. Liste de blocage locale — adresses IP que vous avez bloquées manuellement ou qui ont dépassé les seuils locaux. Stockées dans wp_reportedip_hive_blocked.
3. Web Application Firewall — l’ensemble de règles WAF actif est comparé à l’URI, à la requête, au corps du message et à l’agent utilisateur ; toute correspondance est bloquée via le chemin 403 partagé et codé par référence. Prise en compte de la Whitelist et de l’auteur du contenu pour éviter les False Positives. Un module optionnel à intégrer avant WordPress peut exécuter cette couche avant même le chargement de WordPress.
4. Compteurs de tentatives — les compteurs de Login, de commentaires, d’XMLRPC, de rafales REST et de scans 404 déclenchent un blocage automatique dès que le seuil est atteint.
5. Réputation de la communauté — en mode « Community Network », les adresses IP dont le niveau de confiance est ≥ au seuil sont bloquées en périphérie.
6. Vérification 2FA — les comptes protégés doivent fournir un deuxième facteur d’authentification pour se connecter.

The sixteen Attack Sensors

Chaque capteur peut être activé ou désactivé et réglé indépendamment dans Paramètres → Protection. Les deux dernières lignes — la Block Escalation et le pont de connexion WooCommerce — sont des mécanismes complémentaires s’inscrivant dans le même pipeline plutôt que des capteurs distincts : l’escalade correspond à l’échelle de réponse alimentée par chaque capteur, tandis que le pont WooCommerce comptabilise les échecs de Login à la vitrine en ligne au profit du capteur de Brute Force existant.

Progressive Block Escalation

Les récidivistes paient plus cher. L'échelle par défaut est la suivante : 5 min → 15 min → 30 min → 24 h → 48 h → 7 j. Après 30 jours sans incident, le compteur revient à l'étape 1. Les visiteurs légitimes bloqués pour la première fois (CGNAT, administrateurs ayant fait une erreur de saisie, sortie du réseau mobile) sont débloqués en quelques minutes ; les attaquants persistants atteignent l’étape des 7 jours.

L'échelle, la fenêtre de réinitialisation et le commutateur principal se trouvent sous Paramètres → Blocage → Blocage progressif. L'étape « Protection » de l'assistant affiche le commutateur principal afin que les nouvelles installations prennent en compte l'escalade dès la première sauvegarde. Le paramètre fixe block_duration s'applique toujours lorsque l'échelle est désactivée. Une granularité inférieure à l'heure est fournie par le ReportedIP_Hive_Database::block_ip_for_minutes().

Web Application Firewall et distribution des règles

Depuis la version 2.1.2, Hive intègre un Web Application Firewall inspectant les requêtes. Lorsqu’ init il compare l’ waf ensemble de règles actives à l’URI, à la chaîne de requête, au corps de la requête et à l’agent utilisateur, et bloque toute correspondance via le chemin 403 partagé, compatible avec la mise en cache et codé par référence. Il est renforcé contre les attaques ReDoS (retour en arrière PCRE limité, mode « fail-open » en cas de règle mal formée), prend en compte les Whitelists et l’auteur du contenu pour éviter les False Positives, et ajoute environ 4 µs d’utilisation du processeur par requête sans aucune requête de base de données supplémentaire lorsqu’un cache d’objets persistant est présent.

Les règles ne sont pas codées en dur dans le plugin. Elles sont fournies par la Rule API de ReportedIP — diffusées par le serveur, versionnées, signées avec Ed25519 et réparties par niveaux sur cinq ensembles de règles (waf, bot_signatures, disposable_domains, scan_paths, tor_exits). Le plugin vérifie chaque ensemble de règles par rapport à une clé publique intégrée avant de l’appliquer et se rabat toujours sur un ensemble de règles de base intégré ; ainsi, un flux altéré, surdimensionné ou inaccessible ne peut jamais corrompre vos règles. Les nouvelles signatures d’attaques sont diffusées à toutes les installations en quelques heures, sans qu’aucune mise à jour du plugin ne soit nécessaire.

• Gratuit sur toutes les formules — le moteur WAF et l’ensemble de règles de base « Paranoia-Level-1 » couvrant l’OWASP Top 10, entièrement utilisables hors ligne en mode « Local Shield » à partir de la base intégrée.
• Priority Sync (formules Professional et supérieures) — les ensembles de règles Paranoia-Level-2/3 plus approfondis, fréquemment mis à jour et signés (couverture de l’obfuscation et du contournement), ainsi que les flux en temps réel des plages d’adresses IP de bots et des domaines jetables. La formule Free synchronise la base de référence intégrée ; la formule Contributor, une fois par semaine ; les formules Professional et supérieures, quotidiennement.
• Module « Extended Protection » (en option) — un module pré-WordPress auto_prepend_file qui exécute le WAF avant le chargement de WordPress. Les piles Apache (.htaccess) et PHP-FPM — y compris nginx + PHP-FPM — sont automatiquement configurées via un répertoire racine .user.ini, qui couvre tous les Endpoints PHP indépendamment des location (depuis la version 2.1.17) ; les piles ne disposant pas d’une SAPI PHP FastCGI bénéficient d’une ligne dans le fichier php.ini ou dans le panneau d’hébergement auto_prepend_file ou un extrait de code nginx fastcgi_param extrait de l’onglet « Configuration du serveur ». Par défaut, le garde ignore l’inspection du corps de la requête pour les requêtes authentifiées ; ainsi, les éditeurs connectés qui enregistrent du contenu ne le déclenchent jamais. Les règles relatives aux URL et aux user-agents s’appliquent toujours, et le moteur intégré à WordPress reste le dispositif de sécurité tenant compte des capacités. Désactivé par défaut ; sa suppression supprime les directives contrôlées par Hive et neutralise le garde en le transformant en un espace réservé inerte au lieu de le supprimer (depuis la version 2.1.8), de sorte qu’une directive résiduelle dans un fichier php.ini ou une configuration nginx modifiée manuellement ne peut jamais pointer vers un fichier manquant et provoquer une erreur 500 sur le site. La désactivation du moteur WAF ou le passage en mode « rapport uniquement » neutralise également automatiquement le garde.
• Codes de référence — chaque bloc (WAF ou capteur) porte un code corrélable tel que WAF_SQLI-3F9A2B71, affiché sur la page de blocage et émis dans l’en-tête X-RIP-Ref en-tête. Un visiteur bloqué par erreur fournit une courte chaîne de caractères que l’administrateur peut retrouver dans les journaux ; ce jeton est un hachage à sens unique de l’adresse IP, du motif et de l’heure, de sorte qu’aucune donnée personnelle n’est exposée.

La configuration et l’état en temps réel se trouvent dans le menu dédié au pare-feu : un mini-Dashboard « Aperçu » (état par module, compteurs sur 7 jours, événements récents du pare-feu), un onglet WAF (moteur / mode / sélecteur de niveau de paranoïa), un onglet « Vérification des bots », un onglet « Défense anti-spam » (adresses e-mail jetables + honeypot), une vue d’état de Rule Sync et un onglet « Configuration du serveur » qui regroupe tous les extraits de code du serveur web en un seul endroit.

WAF Exceptions — Gestion des False Positives

Depuis la version 2.1.9, un False Positive peut être résolu depuis l’interface d’administration sans modifier le code — à l’instar du fonctionnement des exclusions ModSecurity et de l’Allowlist de Wordfence. Un endpoint propriétaire qui reçoit légitimement des Payloads ressemblant à des attaques (un formulaire acceptant du code HTML, une API de sécurité ingérant des données d’attaques signalées, un constructeur de pages publiant du balisage brut) déclenche parfois une signature d’injection ; une exception permet à ce cas particulier de passer tandis que le moteur continue de protéger tout le reste.

• Où ? Pare-feu → WAF → WAF Exceptions, plus une action « Autoriser » en un clic sur chaque ligne du journal WAF qui préremplit une exception ciblée pour exactement cette règle sur ce chemin — pas besoin de connaître l’ID de la règle par cœur.
• Portées. Une exception cible une règle unique (par ID de règle, extrait du journal des blocages du WAF), un groupe de règles (sélectionné parmi les catégories connues du moteur) ou — pour un Endpoint propriétaire — l’ensemble du moteur sur un chemin, éventuellement restreint à une plage d’adresses IP ou CIDR. Une exception portant sur l’ensemble du moteur doit toujours comporter une restriction de chemin d’accès ou d’adresse IP, afin que le pare-feu ne puisse jamais être désactivé globalement par accident.
• Définissez son champ d’application de manière aussi restrictive que possible. Préférez une règle unique sur un chemin à un groupe de règles, et un groupe de règles à une exception portant sur l’ensemble du moteur. Le journal des blocages enregistre la valeur correspondante, la cible inspectée, la méthode de requête, l’URI et l’agent utilisateur (depuis la version 2.1.11), ce qui vous permet de voir exactement quelle règle s’est déclenchée et pourquoi avant de l’autoriser.
• La Extended Protection respecte cette même liste. Les exceptions actives sont intégrées au filtre de sécurité pré-WordPress et réactualisées à chaque modification de l’Allowlist — la couche pré-WordPress et le moteur intégré à WordPress sont toujours en accord.
• Multisite et formules d’abonnement. Les exceptions constituent des données à l’échelle du réseau, disponibles sur toutes les formules d’abonnement — le moteur de protection lui-même reste gratuit.
• Porte de secours pour les développeurs. apply_filters('reportedip_hive_waf_bypass_routes', []) Exclut les routes REST au niveau du code. La correspondance s’effectue via un test de préfixe ancré par rapport à la route REST WP résolue — jamais via une sous-chaîne non ancrée de l’URI brute — ; ainsi, un jeton de contournement introduit clandestinement dans un paramètre de requête sans rapport ne peut pas désactiver le WAF.

Verified Bot Detection, Disposable-Email Blocking et Comment Honeypot

• Verified Bot Detection (gratuite). Permet de confirmer qu’une requête se présentant comme provenant de Googlebot, Bingbot ou d’un autre robot d’indexation provient bien de celui-ci — d’abord par une correspondance sans DNS avec les plages d’adresses IP officielles du robot (Priority Sync), puis par un recours au Reverse DNS confirmé en amont qui résout à la fois les enregistrements A et AAAA. Les usurpateurs sont signalés (par défaut) ou bloqués ; un robot d’indexation authentique n’est jamais bloqué. facebookexternalhit Vérification par rapport aux plages d’adresses IP publiées par Meta.
• Disposable-Email Blocking (gratuit). Vérifie l’adresse fournie lors de l’inscription (WordPress et WooCommerce) par rapport à la liste des adresses e-mails jetables. Trois modes : désactivé / surveillance / blocage. Les relais de confidentialité (Apple « Hide My Email », Firefox Relay, etc.) constituent une catégorie distincte qui est autorisée par défaut. La liste en temps réel s’appuie sur Priority Sync.
• Comment Honeypot (gratuit). Un champ leurre invisible, exclu des lecteurs d’écran, sur le formulaire de commentaires ; les robots spammeurs qui remplissent tous les champs sont rejetés sans que les visiteurs réels ne subissent les inconvénients du CAPTCHA.

Blocage des nœuds de sortie Tor (Professional)

Depuis la version 2.1.41, Hive peut rejeter les connexions provenant de nœuds de sortie Tor connus. Cette fonctionnalité est strictement optionnelle — le bouton se trouve sous Paramètres → Blocage et est désactivé par défaut — et nécessite la formule Professional : la liste des nœuds de sortie est fournie sous forme de tor_exits via la Rule Sync régulière et est actualisée deux fois par jour côté serveur, ce qui lui permet de rester à jour malgré la rotation des nœuds de sortie. Le drapeau de isTor indicateur de réputation de la communauté couvre les adresses que la liste n’a pas encore répertoriées.

Les blocages Tor sont délibérément modérés. Ils sont temporaires — 24 heures par défaut, réglables via le reportedip_hive_tor_block_hours filtre — et ne sont jamais signalés à la communauté, car l’exploitation d’un nœud de sortie Tor ne constitue pas une preuve d’abus. Les adresses IP figurant sur la liste Whitelist ne sont jamais bloquées par Tor. Une fois le blocage expiré, la requête suivante réévalue la liste actuelle des nœuds de sortie.

Sources de proxy de confiance (Cloudflare, proxys inversés, équilibreurs de charge)

Lorsque votre site fonctionne derrière Cloudflare, un proxy inverse ou un équilibreur de charge, le pair qui se connecte est le proxy — l’adresse réelle du visiteur est transmise dans un en-tête HTTP tel que CF-Connecting-IP ou X-Forwarded-For. Sélectionnez cet en-tête sous Paramètres → Général → En-tête IP de confiance, et depuis la version 2.1.41, déclarez les adresses du proxy dans la liste Sources de proxy de confiance située juste en dessous — une adresse IP ou une plage CIDR par ligne, par exemple les plages Cloudflare publiées.

Une fois cette liste mise en place, l’en-tête n’est pris en compte que pour les requêtes provenant effectivement d’une adresse de proxy déclarée. Quiconque accède directement à l’origine ne peut pas usurper l’en-tête pour se faire passer pour une adresse figurant sur la Whitelist ou contourner un blocage actif. Une liste vide conserve le comportement précédent (en-tête accepté depuis n’importe quel pair), de sorte que les configurations existantes continuent de fonctionner — mais si vous faites confiance à un en-tête, déclarez vos proxys. La même vérification est appliquée dans le filtre « Extended Protection » pré-WordPress.

Security Headers

Renforcement des en-têtes de réponse sur chaque requête front-end. Les en-têtes déjà envoyés par votre serveur ou par un autre plugin sont détectés et laissés intacts.

• Trio de base (gratuit) — X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Avancé (Professional) — HSTS, Permissions-Policy, une politique de sécurité du contenu (Content-Security-Policy, en mode « rapport uniquement » par défaut, avec un générateur) et le trio d’isolation inter-origines (COOP / CORP / COEP).

L'onglet « Configuration du serveur » permet en outre d'exporter les en-têtes configurés au format nginx add_header / Apache Header au niveau du serveur.

Protection & Hardening Score

Deux jauges du Dashboard (de 0 à 100, plus une note de A+ à F, à la manière de Mozilla Observatory) évaluent votre couverture de détection et votre niveau de renforcement de la sécurité, avec des liens directs vers chaque élément pour activer un capteur. Les fonctionnalités verrouillées (payantes) sont prises en compte dans le potentiel visible, mais n’affectent pas votre score — la formule Free peut donc tout de même atteindre la meilleure note.

Dashboard de sécurité et analyses

Le Dashboard principal s’ouvre sur une bande d’en-tête — attaques bloquées au cours des 30 derniers jours, attaques bloquées aujourd’hui, adresses IP actuellement bloquées et nombre de vos couches de protection activées (par exemple 17 / 20). En dessous, les analyses s’appuient sur toutes les données des capteurs, et ne se limitent pas aux compteurs classiques de Login ou de spam.

• Chronologie des événements de sécurité. Un diagramme à aires empilées regroupant toutes les activités en sept catégories — Login et identifiants, Pare-feu (WAF), Scanners et sondes, Faux bots, Reconnaissance et énumération, Spam et inondations, et Anomalies — sur une période sélectionnable de 7, 30 ou 90 jours.
• Répartition des menaces. Une ventilation indiquant quelle famille d’attaques a dominé la période, afin que vous puissiez voir d’un seul coup d’œil si vous êtes confronté à des attaques par Brute Force, à des tentatives d’exploitation au niveau du pare-feu, à des scanners ou à du spam.
• Pare-feu — Principaux types d’attaques. Classement des blocages du WAF par groupe de règles (SQL Injection, cross-site scripting, traversée de chemin, Log4Shell, agents utilisateurs de scanners, etc.).
• Répartition par niveau de gravité. Nombre d’événements critiques / élevés / moyens / faibles, afin que le volume des événements graves ne soit jamais masqué dans un total unique.
• Principaux attaquants (30 jours). Les adresses IP sources les plus actives avec leur nombre d’accès, la date de leur dernière détection et s’elles sont actuellement bloquées ou simplement surveillées.
• Activité récente. Le flux d’événements en temps réel, chaque entrée étant associée à sa gravité et à sa famille de menaces, ainsi qu’aux détails pertinents (règle WAF correspondante, chemin exploré, nom de bot usurpé par le Spoofing).

Tous les chiffres sont réels, quel que soit le forfait — le Dashboard reflète ce que votre site a réellement bloqué. Les formules « Professional » et « Business » ajoutent des analyses plus approfondies (historique et conservation des journaux plus longs, géolocalisation des attaquants et piste d’audit conforme aux normes de conformité décrite ci-dessous).

Depuis la version 2.1.41, les chiffres clés s’affichent également sous forme de widget de sécurité directement sur le Dashboard WordPress lui-même : les attaques bloquées au cours des 30 derniers jours, les blocages du jour, les adresses IP activement bloquées, les couches de protection et le score de détection apparaissent directement sur la page d’accueil du Dashboard de WordPress, avec des liens directs vers le plugin. Sur les installations Multisite, le widget s’affiche sur le Dashboard du réseau et, pour les super-administrateurs, sur les Dashboard des sous-sites avec les chiffres à l’échelle du réseau.

Audit Event Trail (Business)

Une piste d’audit du cycle de vie des utilisateurs en mode « ajout seul » — Logins, échecs de Login, réinitialisations de mot de passe, mises à jour de profil, changements de rôle (y compris l’utilisateur par intérim), inscriptions et détection de nouvelles adresses IP — avec filtres, exportation CSV / JSON, l’intégration de l’exportation/effacement conforme au RGPD de WordPress et le nettoyage des données conservées (1 an pour la formule Business, configurable pour la formule Enterprise). Stocké dans la audit_log (schéma v9). Les journaux de sécurité standard de 30 jours restent disponibles sur toutes les formules ; la piste d’audit constitue l’enregistrement de niveau conformité qui vient s’y ajouter.

MainWP Integration

Hive peut être géré à distance depuis un Dashboard MainWP sans plugin enfant supplémentaire et sans extension MainWP à acheter. Il s’intègre au filtre « MainWP Child » mainwp_child_extra_execution , de sorte que chaque tâche est authentifiée par le canal MainWP Child existant — pas d’identifiants supplémentaires, pas de nouvelle surface d’attaque. La configuration est simple : installez MainWP Child et Hive sur le site géré, connectez le site à votre Dashboard MainWP comme d’habitude, et le tour est joué.

Deux types de tâches sont pris en charge :

• Synchronisation des métriques de sécurité — uniquement les comptages agrégés : blocages actifs, taille de la Whitelist, tentatives de Login échouées, spam dans les commentaires, blocages liés à la réputation, taille de la file d’attente, événements critiques récents, utilisateurs utilisant l’authentification à deux facteurs (2FA). Depuis la version 2.1.6, la synchronisation rend également compte de l’état du pare-feu (waf_enabled, waf_report_only, waf_dropin_enabled, waf_dropin_running, waf_server ainsi qu’un indicateur dérivé waf_needs_setup ), ce qui permet à un Dashboard de signaler les sites dont la « Extended Protection » est activée mais ne fonctionne pas encore — généralement un hôte nginx qui attend toujours son snippet serveur.
• Provisionnement (reportedip_hive_provision) — envoie une API Key à un site géré depuis le Dashboard de confiance et, depuis la version 2.1.12, permet en option de le basculer en mode « Community Network » au cours de la même tâche (community indicateur). La tâche de synchronisation signale l’état actuel de chaque site enfant operation_mode.

Aucune adresse IP, aucun nom d’utilisateur, aucun Secret ni aucune API Key ne quittent jamais le site géré — la Payload de la synchronisation se compose uniquement de comptes et d’indicateurs d’état.

Réseaux multisites

La Full Edition est réservée aux réseaux (Network: true, depuis la version 2.0.0) : l’activation par site est masquée par WordPress afin que la configuration de sécurité reste uniforme sur l’ensemble du réseau. Les neuf tables se trouvent toutes sous $wpdb->base_prefix, ce qui fait que chaque décision relative aux menaces s’applique à l’ensemble du réseau : les tentatives de Brute-Force inter-sites sont agrégées dans un compteur central, et un seul blocage exclut l’adresse IP de tous les sous-sites simultanément.

• Les administrateurs du réseau disposent de l’ensemble des paramètres et d’une vue des journaux pour tous les sites.
• Les administrateurs de site sur un sous-site disposent d’une interface utilisateur « Statut / Journaux » en lecture seule, ainsi que de deux options de remplacement modifiables par site : le slug « Frontend 2FA » et les rôles supplémentaires pour l’application de l’authentification à deux facteurs (un sous-site peut appliquer l’authentification à deux facteurs à davantage de rôles, mais jamais à moins).
• Cron ne s’exécute que sur le site principal — pas de synchronisations en double ni de nettoyages par sous-site.
• Les WAF Exceptions concernent l’ensemble du réseau et sont gérées par l’administrateur réseau.

Authentification à deux facteurs (2FA)

Quatre méthodes sont prises en charge et peuvent être combinées par utilisateur. Les Recovery Codes sont générés lors de la première configuration. Les Secrets sont chiffrés au repos (libsodium avec un repli sur OpenSSL).

• TOTP — RFC 6238 (6 chiffres, fenêtre de 30 secondes). Compatible avec Google Authenticator, Authy, 1Password, Bitwarden, …
• E-mail — mot de passe OTP à six chiffres via le fournisseur de messagerie configuré ; débit limité (3 codes toutes les 15 minutes, 5 tentatives de vérification par code, délai de réenvoi de 60 secondes).
• SMS — mot de passe à usage unique (OTP) à six chiffres via le relais SMS managed ReportedIP (formule Professional et supérieures ; voir ci-dessous). Le numéro de téléphone est chiffré au repos.
• WebAuthn — Passkeys, clés de sécurité (YubiKey), authentificateurs de plateforme (Touch ID, Face ID, Windows Hello). Analyseur CBOR interne, aucune dépendance externe.
• Trusted Devices — jetons « se souvenir de cet appareil » (opt-in) avec durée d’expiration configurable (30 jours par défaut). Stockés sous forme de wp_reportedip_hive_trusted_devices sous forme de hachages SHA-256.
• Recovery Codes — 10 codes à usage unique xxxx-xxxx ; alerte de niveau de code faible lorsqu’il en reste ≤ 3.

Clés de sécurité matérielles (YubiKey)

Depuis la série 2.1.33–2.1.36, les clés matérielles FIDO2 sont pleinement prises en charge : la série YubiKey 5 (USB-A, USB-C, Lightning et les modèles NFC à approcher d’un téléphone), la gamme de clés de sécurité de Yubico et tous les autres authentificateurs CTAP2 fonctionnent sur les trois surfaces de vérification : la page interstitielle wp-login, le défi de la vitrine WooCommerce et la page de réinitialisation du mot de passe. Les anciennes clés U2F uniquement (CTAP1) ne sont pas officiellement prises en charge.

• Configuration : ouvrez votre page de profil (Utilisateurs → Profil → Authentification à deux facteurs), sélectionnez « Ajouter une clé de sécurité » → « Clé de sécurité (USB / NFC) », donnez un nom à la clé, puis insérez-la et touchez le contact doré lorsque le navigateur vous y invite. Sur un téléphone, placez la clé à plat contre l’arrière de l’appareil, près du haut (NFC). Aucun code PIN FIDO2 n’est requis pour l’enregistrement.
• Une clé par compte est gratuite. La formule Business ajoute des clés de sécurité avancées : plusieurs clés par compte — enregistrez une deuxième YubiKey et conservez-la en lieu sûr à titre de sauvegarde — ainsi que la détection automatique du modèle (« YubiKey série 5 avec NFC » s'affiche à côté de la clé) et des alertes par e-mail chaque fois qu'une clé est ajoutée ou supprimée.
• Vous avez perdu votre clé ? Connectez-vous à l’aide de l’un de vos Recovery Codes (ou de votre clé de secours avec le forfait Business), puis supprimez la clé perdue sur la page de votre profil. La suppression de la dernière clé désactive définitivement cette méthode.
• Détection des clones — chaque connexion fait incrémenter le compteur de signatures de la clé. Toute authentification dont le compteur n’augmente pas est rejetée, consignée et signalée au titulaire du compte par e-mail, quel que soit le forfait.
• Algorithmes — ES256 sur chaque clé ; Ed25519 est négocié automatiquement sur le micrologiciel YubiKey 5.2.3+ lorsque le serveur dispose de libsodium.

Protection contre les attaques Brute-Force de l'authentification à deux facteurs (2FA)