WordPress-Plugin – ReportedIP Hive (Full Edition)

ReportedIP Hive ist ein von der Community getriebenes WordPress-Sicherheits-Plugin. Es verwandelt jede geschützte Website in einen Sensor: Wenn eine Website angegriffen wird, lernt das Netzwerk daraus, und jede andere Website kann den Angreifer abwehren, noch bevor die erste Anfrage eintrifft. Echtzeit-Threat Intelligence, sechzehn Attack Sensors einschließlich einer Web Application Firewall, 2FA mit vier Methoden, Progressive Block Escalation sowie vom Server bereitgestellte, signierte Firewall-Regelsätze. Open Source, veröffentlicht unter GPLv2+ auf GitHub.

Installation

Setup Wizard (10 Schritte)

Der Assistent wird bei der ersten Aktivierung ausgeführt und kann jederzeit über die Plugin-Einstellungen erneut gestartet werden. Jeder Schritt wird bei jedem Seitenwechsel (einschließlich „Zurück“) sofort serverseitig gespeichert, sodass Sie den Vorgang unterbrechen und fortsetzen können, ohne dass Einstellungen verloren gehen.

Betriebsmodi

Zwei Modi – wechseln Sie jederzeit zwischen ihnen, ohne lokale Daten zu verlieren.

Was Sie in den einzelnen Tarifen erhalten

Das Hive-Plugin selbst ist in der Free tier voll funktionsfähig – lokaler Schutz, alle sechzehn Sensoren, alle vier 2FA-Methoden. Die kostenpflichtigen Stufen umfassen eine verwaltete Zustellungsinfrastruktur (E-Mail und SMS) sowie höhere Community Network-Kontingente. Auf der Seite „Preise“ finden Sie einen vollständigen Vergleich und Informationen zum Upgrade.

Das „Business“-Paket ist mehrfach buchbar. Alle oben genannten „Business“-Angaben gelten pro Lizenz. Buchen Sie beim Bezahlvorgang „Business“ x2, x5, x10 oder x20 (oder ändern Sie dies später im Stripe-Kundenportal), und die täglichen Überprüfungen/Reports, das monatliche Kontingent für 2FA-E-Mails/SMS sowie die Anzahl der Domains skalieren entsprechend Ihrer Lizenzanzahl – z. B. x5 = 75 Domains und 500.000 Überprüfungen pro Tag. Ab der 2-fachen Lizenzanzahl gilt automatisch ein Mengenrabatt. Die PRO-Lizenz bleibt eine Einzellizenz; die Werte für Enterprise sind Unlimited (im Rahmen der fairen Nutzung) und werden niemals multipliziert.

Reihenfolge der Bundle-Verbrauchsabrechnung (PRO und Business): Zunächst wird das monatlich inbegriffene Kontingent (25 SMS / 500 E-Mails bei PRO, 75 / 2.500 bei Business) verbraucht, anschließend das Guthaben des Prepaid-Bundles. Sobald beides aufgebraucht ist, gibt die API den Status „HTTP 429“ zurück und Hive greift auf lokale wp_mail() für E-Mails (oder SMS mit festen Obergrenzen) – andere 2FA-Methoden bleiben weiterhin funktionsfähig. Paketguthaben verfallen nie. Stripe verwendet tax_behavior = inclusive für die Pakete mit Bruttopreisen (PAngV-konform); Reverse Charge / OSS wird automatisch von Stripe Tax abgewickelt.

6-stufige Verteidigung

Hive führt seine Prüfungen der Reihe nach durch – jede Ebene kann die Anfrage unterbrechen, bevor sie die nächste erreicht. Die Überprüfung erfolgt init mit Priorität 1 eingebunden, sodass andere Plugins bei einer blockierten IP-Adresse nicht ausgeführt werden.

1. Whitelist – vertrauenswürdige IP-Adressen und CIDR-Bereiche werden stets zugelassen (Ihr Büro, Überwachungsdienste, …).
2. Lokale Sperrliste – IP-Adressen, die Sie manuell gesperrt haben oder die lokale Schwellenwerte überschritten haben. Gespeichert in wp_reportedip_hive_blocked.
3. Web Application Firewall – der aktive WAF-Regelsatz wird mit der URI, der Abfrage, dem Body und dem User-Agent abgeglichen; bei einem Treffer erfolgt die Blockierung über den gemeinsam genutzten, referenzcodierten 403-Pfad. Whitelist- und autorenbezogene Berücksichtigung zur Vermeidung von False Positives. Ein optionaler Pre-WordPress-Drop-in kann diese Ebene ausführen, noch bevor WordPress überhaupt geladen wird.
4. Versuchszähler – Zähler für Logins, Kommentare, XMLRPC, REST-Bursts und 404-Scans lösen eine automatische Sperrung aus, sobald der Schwellenwert erreicht ist.
5. Community-Reputation – Im Community Network werden IP-Adressen mit einer Konfidenz von ≥ Schwellenwert am Rand blockiert.
6. 2FA-Abfrage – Geschützte Konten müssen einen zweiten Authentifizierungsfaktor angeben, um sich anzumelden.

The sixteen Attack Sensors

Jeder Sensor kann unter „Einstellungen → Schutz“ unabhängig voneinander aktiviert und angepasst werden. Die letzten beiden Zeilen – Block Escalation und die WooCommerce-Anmeldebrücke – sind begleitende Mechanismen, die dieselbe Pipeline nutzen und keine separaten Sensoren darstellen: Die Eskalation ist die Reaktionsleiter, in die jeder Sensor einspeist, und die WooCommerce-Brücke zählt fehlgeschlagene Logins im Shop als Teil des bestehenden Brute-Force-Sensors.

Progressive Block Escalation

Wiederholungstäter müssen mit strengeren Maßnahmen rechnen. Die Standard-Sperrstufen lauten: 5 Min. → 15 Min. → 30 Min. → 24 Std. → 48 Std. → 7 Tage. Nach 30 Tagen ohne Vorfälle wird der Zähler auf Stufe 1 zurückgesetzt. Legitime Besucher, die zum ersten Mal in die Sperre geraten (CGNAT, ungeschickte Administratoren, Datenverkehr über Mobilfunknetze), werden innerhalb von Minuten wieder freigeschaltet; hartnäckige Angreifer erreichen die 7-Tage-Stufe.

Die Stufenfolge, das Rücksetzfenster und der Hauptschalter befinden sich unter „Einstellungen“ → „Blockierung“ → „Progressive Block Escalation“. Im Schritt „Schutz“ des Assistenten wird der Hauptschalter angezeigt, sodass Neuinstallationen bereits ab dem ersten Speichern die Eskalationsfunktion berücksichtigen. Die festgelegte block_duration Einstellung gilt auch dann, wenn die Stufenleiter deaktiviert ist. Eine Granularität im Sub-Stunden-Bereich wird durch die ReportedIP_Hive_Database::block_ip_for_minutes().

Web Application Firewall und Regelbereitstellung

Seit Version 2.1.2 verfügt Hive über eine anforderungsprüfende Web Application Firewall. Sofern init sie gleicht den aktiven waf Regelsatz anhand der URI, des Abfrage-Strings, des Anfragetextes und des User-Agents ab und blockiert Treffer über den gemeinsam genutzten, cachesicheren und referenzcodierten 403-Pfad. Sie ist gegen ReDoS-Angriffe gehärtet (begrenztes PCRE-Backtracking, „Fail-Open“-Verhalten bei fehlerhaften Regeln), berücksichtigt Whitelists und den Autor des Inhalts, um False Positives zu vermeiden, und verursacht bei Vorhandensein eines persistenten Objekt-Caches eine zusätzliche CPU-Belastung von etwa 4 µs pro Anfrage ohne zusätzliche Datenbankabfragen.

Die Regeln sind nicht fest im Plugin hinterlegt. Sie werden über die reportedip.com-Rule API bereitgestellt – serverseitig bereitgestellt, versioniert, mit Ed25519 signiert und gestaffelt über vier Regelsätze (waf, bot_signatures, disposable_domains, scan_paths). Das Plugin überprüft jeden Regelsatz vor der Anwendung anhand eines mitgelieferten öffentlichen Schlüssels und greift stets auf eine mitgelieferte Basisregel zurück, sodass ein manipulierter, übergroßer oder nicht erreichbarer Feed Ihre Regeln niemals beeinträchtigen kann. Neue Angriffssignaturen erreichen alle Installationen innerhalb weniger Stunden, ohne dass eine Plugin-Veröffentlichung erforderlich ist.

• Kostenlos in jedem Tarif – die WAF-Engine und der OWASP-Top-10-Baseline-Regelsatz der Stufe „Paranoia Level-1“, der im „Local Shield“-Modus anhand der mitgelieferten Baseline vollständig offline nutzbar ist.
• Priority Sync (ab Professional) – die umfassenderen, regelmäßig aktualisierten und signierten Paranoia Level-2/3-Regelsätze (Abdeckung von Verschleierung und Umgehungsversuchen) sowie die Live-Feeds für Bot-IP-Bereiche und Wegwerf-Domains. Die Free-Version synchronisiert die mitgelieferte Basis; die Contributor-Version wöchentlich; ab Professional täglich.
• „Extended Protection“ Drop-in (optional) – ein vor WordPress auto_prepend_file Schutz, der die WAF ausführt, bevor WordPress geladen wird. Apache (.htaccess) und PHP-FPM-Stacks – einschließlich nginx + PHP-FPM – werden automatisch über einen Document-Root .user.ini, der jeden PHP-Endpoint unabhängig von den nginx-Blöcken abdeckt location (seit 2.1.17); Stacks ohne FastCGI-PHP-SAPI erhalten eine Eintragung in der `php.ini` oder im Hosting-Panel auto_prepend_file Zeile oder ein nginx fastcgi_param aus dem Reiter „Server-Einrichtung“. Der Guard überspringt standardmäßig die Überprüfung des Request-Bodies bei authentifizierten Anfragen, sodass angemeldete Redakteure beim Speichern von Inhalten den Guard niemals auslösen; URL- und User-Agent-Regeln werden weiterhin ausgeführt, und die WordPress-eigene Engine bleibt die auf Berechtigungen basierende Sicherheitsbarriere. Standardmäßig deaktiviert; beim Entfernen werden die von Hive kontrollierten Direktiven entfernt und der Guard in einen inaktiven Platzhalter umgewandelt, anstatt ihn zu löschen (seit Version 2.1.8), sodass eine übrig gebliebene Direktive in einer manuell bearbeiteten `php.ini`- oder Nginx-Konfiguration niemals auf eine fehlende Datei verweisen und einen 500-Fehler auf der Website verursachen kann. Das Deaktivieren der WAF-Engine oder das Umschalten auf den reinen Modus für Reports neutralisiert den Schutzmechanismus ebenfalls automatisch.
• Referenzcodes – jeder Block (WAF oder Sensor) trägt einen zuordenbaren Code wie WAF_SQLI-3F9A2B71, der auf der Blockseite angezeigt und als X-RIP-Ref Header ausgegeben. Ein fälschlicherweise blockierter Besucher gibt eine kurze Zeichenfolge an, die ein Administrator in den Protokollen abgleichen kann; das Token ist ein Einweg-Hash aus IP-Adresse, Grund und Uhrzeit, sodass keine personenbezogenen Daten offengelegt werden.

Konfiguration und Live-Status finden Sie im speziellen Menü „Firewall“: ein Mini-Dashboard „Übersicht“ (Status pro Modul, 7-Tage-Zähler, aktuelle Firewall-Ereignisse), eine Registerkarte „WAF“ (Engine / Modus / Auswahl des „Paranoia Levels“), eine Registerkarte „Bot-Überprüfung“, eine Registerkarte „Spam-Abwehr“ (Wegwerf-E-Mail + Honeypot), eine Statusansicht für Rule Sync sowie eine Registerkarte „Server-Einrichtung“, die alle Webserver-Einstellungen an einem Ort zusammenfasst.

WAF Exceptions – Umgang mit False Positives

Seit Version 2.1.9 können False Positives vom Administrator behoben werden, ohne den Code zu ändern – ähnlich wie bei den ModSecurity-Ausschlüssen und der Wordfence-Allowlist. Ein First-Party-Endpoint, der legitimerweise angreiferähnliche Payloads empfängt (ein Formular, das HTML akzeptiert, eine Sicherheits-API, die gemeldete Angriffsdaten aufnimmt, ein Page-Builder, der rohes Markup übermittelt), löst gelegentlich eine Injektionssignatur aus; eine Ausnahme lässt diesen einen Fall durch, während die Engine alles andere weiterhin schützt.

• Wo: Firewall → WAF → WAF Exceptions, ergänzt durch eine Ein-Klick-Aktion „Zulassen“ für jede WAF-Protokollzeile, die automatisch eine eng gefasste Ausnahme für genau diese Regel auf diesem Pfad vorbelegt – Sie müssen die Regel-ID nicht auswendig kennen.
• Geltungsbereiche. Eine Ausnahme bezieht sich auf eine einzelne Regel (anhand der Regel-ID aus dem WAF-Blockprotokoll), eine Regelgruppe (aus den bekannten Kategorien der Engine) oder – bei einem First-Party-Endpoint – die gesamte Engine auf einem Pfad, optional eingegrenzt auf einen IP- oder CIDR-Bereich. Eine Ausnahmeregel für die gesamte Engine muss stets eine Pfad- oder IP-Einschränkung enthalten, damit die Firewall niemals versehentlich global deaktiviert werden kann.
• Grenzen Sie den Geltungsbereich so eng wie möglich ein. Bevorzugen Sie eine einzelne Regel auf einem Pfad gegenüber einer Regelgruppe und eine Regelgruppe gegenüber einer Ausnahmeregel für die gesamte Engine. Das Blockprotokoll zeichnet den abgeglichenen Wert, das überprüfte Ziel, die Anfragemethode, die URI und den User-Agent (ab Version 2.1.11) auf, sodass Sie genau sehen können, welche Regel ausgelöst wurde und warum, bevor Sie den Zugriff zulassen.
• „Extended Protection“ berücksichtigt dieselbe Liste. Aktive Ausnahmen werden in den „Pre-WordPress“-Drop-in-Schutz integriert und bei jeder Änderung der Allowlist neu integriert – die „Pre-WordPress“-Ebene und die „In-WordPress“-Engine sind stets aufeinander abgestimmt.
• Multisite & Tarife. Ausnahmen sind netzwerkweite Daten, die in jedem Tarif verfügbar sind – die Schutz-Engine selbst bleibt kostenlos.
• Ausweichmöglichkeit für Entwickler. apply_filters('reportedip_hive_waf_bypass_routes', []) Schließt REST-Routen auf Code-Ebene aus. Der Abgleich erfolgt durch einen verankerten Präfix-Test anhand der aufgelösten WP-REST-Route – niemals durch eine unverankerte Teilzeichenfolge der rohen URI –, sodass ein in einen nicht zusammenhängenden Abfrageparameter eingeschleustes Umgehungstoken die WAF nicht deaktivieren kann.

Verified Bot Detection, Disposable-Email Blocking & Comment Honeypot

• Verified Bot Detection (Free). Stellt sicher, dass eine Anfrage, die vorgibt, von Googlebot, Bingbot oder einem anderen Crawler zu stammen, tatsächlich von diesen stammt – zunächst erfolgt ein DNS-freier Abgleich mit den offiziellen IP-Bereichen des Crawlers (Priority Sync), anschließend ein durch Forward-DNS bestätigter Reverse DNS-Fallback, der sowohl A- als auch AAAA-Einträge auflöst. Spoofer werden markiert (Standard) oder blockiert; ein echter Crawler wird niemals blockiert. facebookexternalhit wird anhand der von Meta veröffentlichten IP-Bereiche überprüft.
• Disposable-Email Blocking (Free). Überprüft die bei der Registrierung (WordPress und WooCommerce) angegebene Adresse anhand der Liste für Wegwerf-E-Mail-Adressen. Drei Modi – aus / überwachen / blockieren. Datenschutz-Relays (Apple „Hide My Email“, Firefox Relay, …) bilden eine eigene Kategorie, die standardmäßig durchgelassen wird. Die Live-Liste basiert auf Priority Sync.
• Comment Honeypot (Free). Ein unsichtbares, von Screenreadern ignoriertes Köderfeld im Kommentarformular; Spam-Bots, die jedes Feld ausfüllen, werden abgelehnt, ohne dass echte Besucher durch CAPTCHA-Hürden behindert werden.

Security Headers

Verstärkung der Antwort-Header bei jeder Frontend-Anfrage. Header, die bereits von Ihrem Server oder einem anderen Plugin gesendet wurden, werden erkannt und unverändert belassen.

• Basis-Trio (Free) — X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Erweitert (Professional) – HSTS, Permissions-Policy, eine Content-Security-Policy (standardmäßig nur zur Erstellung von Reports, mit einem Generator) sowie das Trio zur domänenübergreifenden Isolierung (COOP / CORP / COEP).

Über die Registerkarte „Server-Einrichtung“ können die konfigurierten Header zusätzlich als nginx-Konfiguration auf Serverebene add_header / Apache Header -Direktiven auf Serverebene exportieren.

Protection & Hardening Score

Zwei Dashboard-Anzeigen (0–100 sowie eine Note von A+ bis F im Stil des Mozilla-Observatory) bewerten Ihre Erkennungsabdeckung und Ihren Absicherungsstatus, mit Deep-Links zu den einzelnen Elementen, über die Sie einen Sensor aktivieren können. Gesperrte (kostenpflichtige) Funktionen fließen in das sichtbare Potenzial ein, wirken sich jedoch nicht negativ auf Ihre Bewertung aus – somit kann auch das Free tier eine Bestnote erreichen.

Sicherheits-Dashboard und Analysen

Das Haupt-Dashboard öffnet sich mit einer Kopfzeile – in den letzten 30 Tagen abgewehrte Angriffe, heute abgewehrte Angriffe, derzeit gesperrte IP-Adressen und die Anzahl Ihrer aktivierten Schutzebenen (zum Beispiel 17 / 20). Darunter werden die Analysedaten aus allen Sensoren angezeigt, nicht nur die klassischen Zähler für Login und Spam.

• Zeitleiste der Sicherheitsereignisse. Ein gestapeltes Flächendiagramm, das alle Aktivitäten in sieben Kategorien gruppiert – Login & Anmeldedaten, Firewall (WAF), Scanner & Sonden, gefälschte Bots, Aufklärung & Enumeration, Spam & Flooding sowie Anomalien – über einen wählbaren Zeitraum von 7, 30 oder 90 Tagen.
• Verteilung der Bedrohungen. Eine Aufschlüsselung, welche Angriffsfamilie den Zeitraum dominierte, sodass Sie auf einen Blick erkennen können, ob Sie mit Brute-Force-Angriffen, Exploit-Versuchen auf Firewall-Ebene, Scannern oder Spam konfrontiert sind.
• Firewall – Häufigste Angriffstypen. Die von der WAF blockierten Angriffe, sortiert nach Regelgruppen (SQL Injection, Cross-Site-Scripting, Path-Traversal, Log4Shell, User-Agents von Scannern, …).
• Aufschlüsselung nach Schweregrad. Anzahl der Ereignisse der Stufen „Kritisch“, „Hoch“, „Mittel“ und „Niedrig“, sodass das Ausmaß schwerwiegender Vorfälle niemals in einer einzigen Gesamtsumme verborgen bleibt.
• Top-Angreifer (30 Tage). Die aktivsten Quell-IPs mit ihrer Trefferzahl, dem Zeitpunkt ihrer letzten Erfassung sowie der Angabe, ob sie derzeit blockiert oder nur überwacht werden.
• Aktuelle Aktivitäten. Der Live-Ereignisstrom, wobei jeder Eintrag mit seinem Schweregrad und der Bedrohungsfamilie sowie den relevanten Details (abgeglichene WAF-Regel, abgefragter Pfad, gefälschter Bot-Name) gekennzeichnet ist.

Alle Zahlen sind in jedem Tarif in Echtzeit verfügbar – das Dashboard spiegelt wider, was Ihre Website tatsächlich blockiert hat. Die Tarife „Professional“ und „Business plan“ bieten darüber hinaus detailliertere Analysen (längere Verlaufs- und Protokollaufbewahrung, geografische Verteilung der Angreifer sowie den unten beschriebenen, Compliance-konformen Prüfpfad).

Audit Event Trail (Business)

Ein ausschließlich nachträglich ergänzbarer Verlauf des Benutzerlebenszyklus – Logins, fehlgeschlagene Logins, Passwortzurücksetzungen, Profilaktualisierungen, Rollenänderungen (einschließlich des stellvertretenden Benutzers), Registrierungen und Erkennung neuer IP-Adressen – mit Filtern, CSV-/ JSON-Export, WordPress-DSGVO-Export-/Löschintegration sowie Bereinigung der Aufbewahrungsfristen (1 Jahr im Business-Tarif, im Enterprise-Tarif konfigurierbar). Gespeichert in der dedizierten audit_log Tabelle (Schema v9) gespeichert. Die standardmäßigen 30-Tage-Sicherheitsprotokolle bleiben in jedem Tarif verfügbar; der Prüfpfad ist die darüber hinausgehende Aufzeichnung auf Compliance-Niveau.

MainWP Integration

Hive lässt sich über ein MainWP-Dashboard fernverwalten, ohne dass ein zusätzliches Child-Plugin oder eine MainWP-Erweiterung erworben werden muss. Es bindet sich in den MainWP-Child-Filter mainwp_child_extra_execution , sodass jeder Auftrag über den bestehenden MainWP-Child-Kanal authentifiziert wird – keine zusätzlichen Anmeldedaten, keine neue Angriffsfläche. Die Einrichtung ist ganz einfach: Installieren Sie MainWP Child und Hive auf der verwalteten Website, verbinden Sie die Website wie gewohnt mit Ihrem MainWP-Dashboard – fertig.

Es werden zwei Auftragstypen unterstützt:

• Synchronisierung von Sicherheitskennzahlen – ausschließlich aggregierte Werte: aktive Blockierungen, Größe der Whitelist, fehlgeschlagene Logins, Kommentar-Spam, Reputationsblockierungen, Größe der Warteschlange, aktuelle kritische Ereignisse, 2FA-aktivierte Benutzer. Seit Version 2.1.6 berichtet die Synchronisierung auch über den Firewall-Status (waf_enabled, waf_report_only, waf_dropin_enabled, waf_dropin_running, waf_server sowie ein daraus abgeleitetes waf_needs_setup Flag) – so kann ein Dashboard Websites kennzeichnen, bei denen der Extended Protection aktiviert, aber noch nicht aktiv ist – typischerweise ein Nginx-Host, der noch auf sein Server-Snippet wartet.
• Bereitstellung (reportedip_hive_provision) – Übertragen Sie einen API Key vom vertrauenswürdigen Dashboard an eine verwaltete Website und schalten Sie diese seit Version 2.1.12 optional im selben Auftrag in den Community Network-Modus um (community Flag). Der Synchronisierungsauftrag Reports den aktuellen Status jeder untergeordneten Website operation_mode.

IP-Adressen, Benutzernamen, Geheimnisse oder der API Key verlassen niemals die verwaltete Website – die Payload besteht ausschließlich aus Zählwerten und Statusflags.

Multisite-Netzwerke

Die Full Edition ist ausschließlich für Netzwerke vorgesehen (Network: true, seit Version 2.0.0): Die Aktivierung auf Einzelseitenebene wird von WordPress verborgen, sodass die Sicherheitskonfiguration im gesamten Netzwerk einheitlich bleibt. Alle neun Tabellen befinden sich unter $wpdb->base_prefix, wodurch jede Entscheidung bezüglich Sicherheitsbedrohungen netzwerkweit getroffen wird – siteübergreifende Brute-Force-Versuche werden in einem zentralen Zähler zusammengefasst, und eine einzige Sperre schließt die IP-Adresse sofort von allen Unterseiten aus.

• Netzwerkadministratoren erhalten den vollständigen Einstellungsumfang sowie eine Protokollansicht für alle Seiten.
• Seitenadministratoren einer Unterseite erhalten eine schreibgeschützte Benutzeroberfläche für Status und Protokolle sowie genau zwei bearbeitbare, standortspezifische Übersteuerungen: den „Frontend 2FA“-Slug und zusätzliche Rollen für die 2FA-Durchsetzung (eine Unterseite kann 2FA für mehr Rollen erzwingen, niemals für weniger).
• Cron-Aufträge werden ausschließlich auf der Hauptseite ausgeführt – es erfolgen keine doppelten Synchronisierungen oder Bereinigungsläufe pro Unterseite.
• WAF Exceptions sind netzwerkweite Daten, die vom Netzwerkadministrator verwaltet werden.

Zwei-Faktor-Authentifizierung (2FA)

Es werden vier Methoden unterstützt, die pro Benutzer kombiniert werden können. Recovery Codes werden bei der Ersteinrichtung generiert. Geheimnisse werden im Ruhezustand verschlüsselt (libsodium mit einem OpenSSL-Fallback).

• TOTP – RFC 6238 (6 Ziffern, 30-Sekunden-Fenster). Funktioniert mit Google Authenticator, Authy, 1Password, Bitwarden, …
• E-Mail – sechsstelliges OTP über den konfigurierten E-Mail-Anbieter; mit Rate Limiting (3 Codes alle 15 Minuten, 5 Verifizierungsversuche pro Code, 60 Sekunden Wartezeit bis zum erneuten Versand).
• SMS – sechsstelliges OTP über den verwalteten reportedIP-SMS Relay (ab Professional-Tarif; siehe unten). Die Telefonnummer wird im Ruhezustand verschlüsselt.
• WebAuthn – Passkeys, Sicherheitsschlüssel (YubiKey), plattformbasierte Authentifikatoren (Touch ID, Face ID, Windows Hello). Interner CBOR-Parser, keine Abhängigkeit von externen Komponenten.
• Trusted Devices – Opt-in-Token zum Speichern des Geräts mit konfigurierbarer Gültigkeitsdauer (standardmäßig 30 Tage). Gespeichert als wp_reportedip_hive_trusted_devices als SHA-256-Hashes.
• Recovery Codes – 10 Einmal-Codes xxxx-xxxx Codes; Warnung bei niedrigem Stand bei ≤ 3 verbleibenden Codes.

Hardware Security Key (YubiKey)

Seit der Versionsreihe 2.1.33–2.1.36 werden FIDO2-Hardware-Schlüssel voll unterstützt: Die YubiKey-5-Serie (USB-A, USB-C, Lightning sowie die NFC-Modelle, die an ein Smartphone gehalten werden), die „Security Key by Yubico“-Reihe und alle anderen CTAP2-Authentifikatoren funktionieren auf allen drei Herausforderungsflächen – dem „wp-login“-Interstitial, der WooCommerce-Storefront-Herausforderung und dem Passwort-Reset-Bildschirm. Ältere, ausschließlich U2F-fähige Schlüssel (CTAP1) werden offiziell nicht unterstützt.

• Einrichtung: Öffnen Sie Ihre Profilseite (Benutzer → Profil → Zwei-Faktor-Authentifizierung), wählen Sie „Sicherheitsschlüssel hinzufügen“ → „Sicherheitsschlüssel (USB / NFC)“, geben Sie dem Schlüssel einen Namen, stecken Sie ihn ein und berühren Sie den goldenen Kontakt, wenn der Browser Sie dazu auffordert. Auf einem Smartphone halten Sie den Schlüssel flach an die Rückseite im oberen Bereich (NFC). Für die Registrierung ist keine FIDO2-PIN erforderlich.
• Ein Schlüssel pro Konto ist kostenlos. Der Business plan bietet erweiterte Sicherheitsschlüssel: mehrere Schlüssel pro Konto – registrieren Sie einen zweiten YubiKey und bewahren Sie ihn an einem sicheren Ort als Backup auf – sowie automatische Modellerkennung („YubiKey 5-Serie mit NFC“ wird neben dem Schlüssel angezeigt) und E-Mail-Benachrichtigungen, sobald ein Schlüssel hinzugefügt oder entfernt wird.
• Haben Sie Ihren Schlüssel verloren? Melden Sie sich mit einem Ihrer Recovery Codes (oder Ihrem Backup-Schlüssel im Business-Tarif) an und entfernen Sie anschließend den verlorenen Schlüssel auf Ihrer Profilseite. Durch das Entfernen des letzten Schlüssels wird die Methode vollständig deaktiviert.
• Klonerkennung – Bei jeder Anmeldung wird der Signaturzähler des Schlüssels erhöht. Eine Authentifizierung, bei der sich der Zähler nicht erhöht, wird abgelehnt, protokolliert und dem Kontoinhaber in jedem Tarif per E-Mail gemeldet.
• Algorithmen – ES256 für jeden Schlüssel; Ed25519 wird bei YubiKey-Firmware 5.2.3+ automatisch ausgehandelt, wenn der Server über libsodium verfügt.

Brute-Force-Schutz für 2FA

Die 2FA-Verifizierungsleiter verläuft wie folgt: 3 → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. Erreicht der Zähler die oberste Stufe, wird die IP-Adresse in den zentralen auto_block_ip() Pfad weitergeleitet (Ereignis 2fa_brute_force), was wie bei jedem anderen Sensor eine schrittweise Eskalation und eine Berichterstattung im Community-Modus auslöst.

Headless 2FA REST

Für App-Integrationen stellt das Plugin drei Routen unter dem Namensraum reportedip-hive/v1:

• POST /2fa/challenge — Benutzername + Passwort → Challenge-Token + aktivierte Methoden (20 Anfragen / 5 Minuten pro IP-Adresse).
• POST /2fa/verify — Token + Methode + Code → setzt das Authentifizierungs-Cookie (30 Anfragen / 5 Minuten pro IP-Adresse).
• GET /2fa/methods — Zeigt die aktiven Methoden für den aktuellen Benutzer an.

WooCommerce-Frontend-Login

Die Frontend-2FA von Hive bleibt innerhalb Ihres aktiven Shop-Themes – Kunden, die sich über [woocommerce_my_account], den klassischen Checkout oder die WooCommerce-Blöcke „Warenkorb“ bzw. „Checkout“ anmelden, schließen ihren zweiten Authentifizierungsschritt auf einer themenbezogenen Seite ab. Der Status von Warenkorb und Checkout bleibt während der Weiterleitung erhalten, das Cookie für Trusted Devices wird mit dem wp-login-Ablauf geteilt.

• Konfigurationspfad – 2FA → Frontend-Login für WooCommerce.
• Konfigurierbare Slugs – Challenge-Slug (Standard reportedip-hive-2fa) und Einrichtungs-Slug (Standard reportedip-hive-2fa-setup); beide sind editierbar, werden auf Konflikte geprüft, und die Rewrite-Regeln werden bei Änderungen automatisch aktualisiert.
• Herabstufung des Tarifs – weiche Deaktivierung bei den Tarifen „Free plan“ und „Contributor“; Einstellungen, Slug-Auswahlen und der Onboarding-Status bleiben erhalten, es entsteht kein Datenverlust beim erneuten Upgrade.
• Konflikterkennung – Hive zeigt eine Administrator-Meldung an, wenn „Solid Security“, das WP-Two-Factor-Plugin oder „Wordfence 2FA“ die Kontrolle über das Login-Formular haben, und deaktiviert die Frontend-Abfrage, um doppelte Aufforderungen zu vermeiden.
• Verfügbarkeit der Tarife – ab „Professional“. Die kostenlosen WooCommerce-Sensoren für fehlgeschlagene Logins (woocommerce_login_failed, woocommerce_checkout_login_form_failed_login) sind in jedem Tarif weiterhin verfügbar und speisen den Brute-Force-Zähler fortlaufend.

E-Mail- und SMS-Zustellung

Die E-Mail-Ebene läuft über einen pluggbaren Anbietervertrag (ReportedIP_Hive_Mailer). Der Standardanbieter ist WordPress wp_mail(); Integratoren können einen eigenen Anbieter einsetzen, ohne den Rest des Plugins zu verändern. Ab dem „Professional“-Tarif können Transaktions-E-Mails (2FA-Codes, Sicherheitsbenachrichtigungen) stattdessen über den verwalteten Mail Relay von reportedIP.com versendet werden – eine SPF-, DKIM- und DMARC-konforme Absenderinfrastruktur, sodass OTP-E-Mails nicht im Spam-Ordner landen, wie es bei nicht authentifizierten wp_mail() E-Mails von Shared-Hosting-Anbietern oft im Spam-Ordner landen.

• SMS-2FA ist eine Funktion der Professional-Stufe, die ausschließlich über den verwalteten reportedip.com-Relay bereitgestellt wird – es sind weder ein eigenes SMS-Konto noch Twilio-Zugangsdaten oder ein Mobilfunkvertrag erforderlich. Die Funktion wird bei Abschluss eines kostenpflichtigen Tarifs automatisch konfiguriert; aktivieren Sie sie unter „Einstellungen“ → „2FA“ → „SMS“. Die Wartezeit für erneute Sendeversuche pro Empfänger steigt schrittweise an (0 s → 30 s → 1 m → 2 m → 5 m → 15 m), sodass eine verspätete oder nicht zugestellte SMS ohne Nachteile erneut angefordert werden kann, während ein echter Versandanstieg weiterhin gedrosselt wird.