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 des 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 interrompre 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 le Free tier : 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 version PRO reste à licence unique ; les chiffres de la version Enterprise sont Unlimited (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 à 6 niveaux

Hive applique ses vérifications dans l’ordre — chaque couche peut interrompre la requête avant qu’elle n’atteigne la suivante. Le plugin est configuré 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 boutique 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’ensemble de règles actif 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 quatre ensembles de règles (waf, bot_signatures, disposable_domains, scan_paths). 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 tous les forfaits — le moteur WAF et l’ensemble de règles de base OWASP Top 10 « Paranoia Level-1 », entièrement utilisables hors ligne en mode Local Shield à partir de la base de référence 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 sur les plages d’adresses IP de bots et les domaines jetables. La formule Free synchronise la base de référence intégrée ; la formule Contributor, chaque 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 sans 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 continuent toutefois de s’appliquer, 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) comporte 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, ce qui garantit 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 + Honeypots), une vue de l’é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.
• Extended Protection respecte cette même liste. Les exceptions actives sont intégrées au pare-feu « drop-in » 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 (Free). 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 (Free). Vérifie l’adresse fournie lors de l’inscription (WordPress et WooCommerce) par rapport à la liste des adresses 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 (Free). Un champ leurre invisible, exclu des lecteurs d’écran, sur le formulaire de commentaire ; les robots de spam qui remplissent tous les champs sont rejetés sans que les visiteurs réels aient à passer par un CAPTCHA.

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 (Free) — 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 (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 — le Free tier 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 de zones 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 d’événements graves ne soit jamais masqué par un simple total.
• 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 forfaits « Professional » et « Business » offrent en outre 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).

Audit Event Trail (Business)

Une piste 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 procuration), inscriptions et détection de nouvelles adresses IP — avec des filtres, l’exportation au format CSV / JSON, l’intégration d’exportation/effacement conforme au RGPD pour WordPress et le nettoyage de la conservation des données (1 an pour la formule Business, configurable pour la formule Enterprise). Stockée 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 conforme aux normes de conformité qui s’y ajoute.

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 » dans 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 charge utile 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 de 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 SMS Relay 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.

Hardware Security Key (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 Security Key de Yubico et tous les autres authentificateurs CTAP2 fonctionnent sur les trois surfaces de défi : la page interstitielle wp-login, le défi de la boutique 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. Le Business plan 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 2FA

L'échelle de vérification de l'authentification à deux facteurs (2FA) est la suivante : 3 → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Lorsque le compteur atteint le dernier échelon, l'adresse IP est transférée vers le auto_block_ip() (événement 2fa_brute_force) ce qui déclenche une escalade progressive et des Reports en mode « Community » comme pour tout autre capteur.

Headless 2FA REST

Pour les intégrations d’applications, le plugin expose trois routes sous l’espace de noms reportedip-hive/v1:

• POST /2fa/challenge — nom d’utilisateur + mot de passe → jeton de défi + méthodes activées (20 requêtes / 5 min par adresse IP).
• POST /2fa/verify — jeton + méthode + code → définit le cookie d’authentification (30 requêtes / 5 min par adresse IP).
• GET /2fa/methods — affiche les méthodes actives pour l’utilisateur actuel.

Login front-end WooCommerce

Le Frontend 2FA de Hive s’intègre à votre thème de boutique en ligne actif : les clients se connectant via [woocommerce_my_account], la page de paiement classique ou les blocs « Panier » / « Paiement » de WooCommerce effectuent leur deuxième facteur d’authentification sur une page personnalisée selon le thème. L’état du panier et de la page de paiement est conservé après la redirection, et le cookie Trusted Device est partagé avec le flux wp-login.

• Chemin de configuration — 2FA → Login en front-end pour WooCommerce.
• Slugs configurables — slug de vérification (par défaut reportedip-hive-2fa) et slug de configuration (par défaut reportedip-hive-2fa-setup) ; tous deux modifiables, avec vérification des conflits, et les règles de réécriture sont automatiquement actualisées en cas de modification.
• Rétrogradation de forfait — désactivation en douceur sur les forfaits Free et Contributor ; les paramètres, les choix de slugs et l’état d’intégration sont conservés, aucune perte de données lors de la nouvelle mise à niveau.
• Détection des conflits — Hive affiche un message d’administration lorsque Solid Security, le plugin WP Two-Factor ou Wordfence 2FA gère le formulaire de Login, et désactive le défi en interface publique pour éviter les doubles invites.
• Disponibilité des formules — Formule « Professional » et supérieures. Les capteurs gratuits d’échec de Login WooCommerce (woocommerce_login_failed, woocommerce_checkout_login_form_failed_login) restent disponibles sur tous les forfaits et continuent d’alimenter le compteur Brute-Force.

Envoi d’e-mails et de SMS

La couche de messagerie fonctionne via un contrat de fournisseur modulable (ReportedIP_Hive_Mailer). Le fournisseur par défaut est WordPress wp_mail() ; les intégrateurs peuvent le remplacer par leur propre fournisseur sans modifier le reste du plugin. À partir de la formule Professional, les e-mails transactionnels (codes 2FA, notifications de sécurité) peuvent être acheminés via le Mail Relay géré reportedIP.com — une infrastructure d’expédition conforme aux normes SPF, DKIM et DMARC —, ce qui évite que les e-mails contenant des codes OTP ne finissent dans les spams, contrairement à ce qui arrive souvent avec un wp_mail() provenant d’un hébergement mutualisé.

• L’authentification à deux facteurs par SMS est une fonctionnalité de la formule « Professional » fournie exclusivement via le relais géré reportedIP.com — aucun compte SMS personnel, identifiants Twilio ou contrat avec un opérateur n’est requis. Elle est configurée automatiquement avec une formule payante ; activez-la sous Paramètres → 2FA → SMS. Le délai de réenvoi par destinataire augmente progressivement (0 s → 30 s → 1 m → 2 m → 5 m → 15 m), ce qui permet de redemander un SMS lent ou non reçu sans pénalité, tandis qu’un véritable pic de trafic reste limité.