ReportedIP Hive 2.1.36 – Offizielle Unterstützung für YubiKey und Hardware Security Key
Mit ReportedIP Hive 2.1.36 werden Hardware Security Keys zu einem offiziellen, vollwertigen zweiten Authentifizierungsfaktor. Ein YubiKey – oder jeder andere FIDO2-Schlüssel bzw. Plattform-Passkey – führt nun auf allen drei Anmeldeoberflächen (wp-login, der WooCommerce-Storefront und dem Bereich zur Passwortzurücksetzung) einen vollständigen WebAuthn-Vorgang durch, unterstützt durch einen Multi-Key-Manager, eine automatische Schlüsselmodellerkennung und Warnmeldungen bei geklonten Schlüsseln.
Mit dieser Veröffentlichung werden die Entwicklungsphasen 2.1.33 bis 2.1.35 in einem einzigen Update zusammengefasst. Sie können es über „Plugins → Nach Updates suchen“ oder auf der GitHub Releases-Seite herunterladen; falls Sie die vorangegangene Reihe zur Firewall-Absicherung verpasst haben, finden Sie weitere Informationen dazu im Bericht zu Version 2.1.21.
Was hat sich seit Hive 2.1.21 geändert?
Zwischen Version 2.1.23 (09.07.2026) und Version 2.1.36 (05.08.2026) wurden elf Versionen veröffentlicht. Der rote Faden: strengere Durchsetzung mit weniger selbstverschuldeten Fehlern, ein Release mit erheblicher Leistungssteigerung und schließlich der Meilenstein „Hardware-Schlüssel“.
| Version | Änderung der Überschrift |
|---|---|
| 2.1.23 | Die Standard-WAF-Regel blockiert die PHPUnit eval-stdin.php RCE-Test (CVE-2017-9841) in jedem Plan; Benutzer, die die 2FA-Frist überschreiten, werden zur obligatorischen Registrierung weitergeleitet, anstatt gesperrt zu werden. |
| 2.1.24 | Eine doppelte Übermittlung der 2FA-Login-Abfrage führt nicht mehr dazu, dass ordnungsgemäß authentifizierte Benutzer auf einer Seite mit der Meldung „Sitzung abgelaufen“ hängen bleiben. |
| 2.1.25 | Zwei Basisregeln zielen auf die Klasse zur Verhinderung von Verwechslungen bei REST-Batch-Routen im WordPress-Kern ab; Request-Bodies werden sowohl im Rohformat als auch nach einmaliger Dekodierung abgeglichen, wodurch eine Umgehungsmöglichkeit für kodierte Payloads geschlossen wird. |
| 2.1.26 | Crawler-Anfragen werden anhand von vorwärtsbestätigten Reverse-DNS-Einträgen und offiziellen IP-Bereichen abgeglichen; eine zentrale Schutzmaßnahme verhindert, dass ein Sensor einen verifizierten Googlebot automatisch blockiert; Unterseiten von Multisite-Websites lesen nun wieder die richtigen Tabellen aus. |
| 2.1.27 | Ein gefälschter User-Agent „Jetpack by WordPress.com“ schützt Brute-Force-Angriffe auf den Login-Bereich nicht mehr vor der automatischen Sperrung; die Option „Diesem Gerät vertrauen“ bleibt auch nach fehlgeschlagenen Versuchen aktiv. |
| 2.1.28 | Ein „Community-Reputation-Hit“ führt nun zu einer 24-stündigen Sperre, die sich auf alle Seiten erstreckt, nicht nur auf das Formular für den Login; die Mindestversion von WordPress wurde auf 5.9 angehoben. |
| 2.1.29 | Der neue Schalter „Archivseiten der Autoren öffentlich halten“ trennt die tatsächliche Sicherheitslücke bei der User Enumeration (?author=N) von harmlosen Archiv-Links. |
| 2.1.30 | Der „Pre-WordPress“-Schutz führt IP-Sperren durch, bevor WordPress geladen wird, und protokolliert jeden Zugriff in einer Warteschlangendatei – Extended Protection wird schließlich in den Protokollen und der Eskalationsleiter angezeigt. |
| 2.1.31 | Die Block Escalation gewichtet das Angriffsvolumen (bei einer Serie von 60 Verstößen werden Stufen übersprungen); der Server kann seine eigene IP-Adresse nicht mehr automatisch aufgrund von Cache-Preload und Cron-Loopbacks blockieren. |
| 2.1.32 | Leistungsverbesserung: 36 → 11 Plugin-Abfragen pro anonymer Anfrage; die Blocklist-Antworten erfolgen nun über einen 8-KB-Header anstelle des Lesens einer 1-MB-Datei; TTFB des Dashboards 920 ms → 278 ms bei einer Log-Tabelle mit 500.000 Zeilen (Schema v13); CIDR-Bereichsblockierungen werden wieder auf der WordPress-Ebene durchgesetzt. |
| 2.1.36 | Offizielle Unterstützung für YubiKey bzw. Hardware Security Key sowie der überarbeitete Abschnitt „2FA“ im Profil (fasst die Versionen 2.1.33–2.1.35 zusammen). |
Hardware Security Keys sind nun ein vollwertiger zweiter Authentifizierungsfaktor
Hive unterstützt WebAuthn bereits seit Version 1.4.0, doch man konnte es ehrlich gesagt eher als „Passkey-tauglich“ denn als „Hardware-Key-tauglich“ bezeichnen: Die WooCommerce-Challenge zeigte eine Registerkarte „Passkey“ an, deren Bedienfeld jedoch nicht existierte, und die Seite zum Zurücksetzen des Passworts bot WebAuthn an, ohne dabei überhaupt ein entsprechendes Skript zu laden. Version 2.1.36 schließt diese Lücke. Alle drei Anmeldeoberflächen – die wp-login-Zwischenseite, die WooCommerce-Storefront-Anmeldung und die Seite zur Passwortzurücksetzung – zeigen nun ein gemeinsames WebAuthn-Panel an (templates/partials/webauthn-challenge-panel.php) und führen eine vollständige Authentifizierungszeremonie durch.
Die Details des Verfahrens sind auf echte Hardware abgestimmt. Die Zeitüberschreitung wird vom WebAuthn-Standardwert von 60 auf 120 Sekunden erhöht (CEREMONY_TIMEOUT_MS, class-two-factor-webauthn.php), da NFC-Kontakte auf Smartphones in der Regel diese zusätzliche Zeit benötigen. Sofern libsodium verfügbar ist, wird Ed25519 (EdDSA, COSE −8) vor ES256 und RS256 angeboten und serverseitig verifiziert – dies ist der Algorithmus, den die YubiKey-Firmware ab Version 5.2.3 bevorzugt. Und userVerification wird standardmäßig discouraged, gemäß den Leitlinien von Yubico zur Unterscheidung zwischen Anwesenheit und Verifizierung des Benutzers, sodass ein neuer Schlüssel den Benutzer bei einem Zwei-Faktor-Login niemals mit einer FIDO2-PIN-Abfrage überrascht. Betreiber, die eine PIN- oder biometrische Verifizierung wünschen, können die Richtlinie über den reportedip_hive_webauthn_user_verification Filter anheben – und die angehobene Richtlinie wird dann serverseitig durchgesetzt und nicht nur clientseitig angefordert.
Eine weitere bewusste Entscheidung: Bei der Registrierung wird nun residentKey: 'discouraged'. Die Registrierung eines YubiKeys als zweite Authentifizierungsstufe für WordPress belegt nun keinen der begrenzten Speicherplätze für erkennbare Anmeldedaten des Schlüssels mehr (25 bei den meisten Firmware-Versionen der 5er-Serie, 100 ab Firmware 5.7) – die Anmeldedaten werden stattdessen serverseitig gespeichert. Bereits vorhandene erkennbare Anmeldedaten funktionieren weiterhin.
Ein Sicherheitsschlüssel-Manager ist im Benutzerprofil hinterlegt
Jeder Nutzer verfügt nun in seinem Profil über einen Manager für „Sicherheitsschlüssel und Passkeys“: Sie können mehrere Schlüssel registrieren (einen primären sowie einen Ersatzschlüssel), diese benennen und umbenennen, einzeln entfernen sowie einsehen, wann jeder Schlüssel hinzugefügt und zuletzt verwendet wurde. Die Registrierungsschaltflächen enthalten WebAuthn-Hinweise – „Sicherheitsschlüssel (USB / NFC)“ entspricht authenticatorAttachment: cross-platform, „Dieses Gerät“ zu platform —, sodass Chrome und Edge direkt den richtigen Dialog öffnen, anstatt zweimal nachzufragen. Das Entfernen des letzten Schlüssels deaktiviert die Methode über den normalen Deaktivierungsweg, niemals im Hintergrund.
Das Plugin zeigt Ihnen an, welches Schlüsselmodell registriert wurde
Die Registrierung fordert eine direkte Bescheinigung an, überprüft die Signaturen der gepackten Bescheinigungen, extrahiert die AAGUID und gleicht diese mit einer integrierten Datenbank ab, die 91 Authentifikationsmodelle umfasst – 81 Yubico-Hardwareeinträge sowie die wichtigsten Passkey-Plattformen (Windows Hello, iCloud Keychain, Google Password Manager, 1Password und andere), die aus dem Metadatendienst der FIDO Alliance stammen. Das erkannte Modell („YubiKey 5 Series mit NFC“, „Windows Hello“) wird unter dem Schlüsselnamen angezeigt. Der gesamte Vorgang ist rein informativ und „fail-open“: Eine fehlende oder nicht überprüfbare Bescheinigung blockiert niemals eine Registrierung, was den Leitlinien von Yubico entspricht, wonach die Bescheinigung informieren und nicht als Sperre dienen soll.
Geklonte Schlüssel werden erkannt und per E-Mail gemeldet
Authentifikatoren führen einen Signaturzähler, der bei jeder Assertion erhöht werden muss. Eine Assertion, bei der der Zähler nicht erhöht wird, ist das klassische Anzeichen für einen geklonten oder zurückgesetzten Authentifikator; daher lehnt Hive diese nun ab, protokolliert 2fa_webauthn_counter_regression mit hohem Schweregrad und benachrichtigt den Kontoinhaber per E-Mail – bei jedem Tarif, begrenzt auf eine E-Mail pro Zugangsdaten pro Stunde. Plattform-Passkeys ohne Zähler (die legitimerweise den Wert Null melden) funktionieren weiterhin. Authentifizierungsanfragen ohne das „User-Presence“-Flag werden gemäß WebAuthn §7.2 abgelehnt. Die Registrierung und Löschung von Schlüsseln löst im Business plan eigene Benachrichtigungs-E-Mails aus.
Der Abschnitt „2FA“ im Profil wurde für Endnutzer neu gestaltet
Im alten Profilbereich wurde davon ausgegangen, dass Sie wussten, was TOTP bedeutet. Der neu gestaltete Bereich nutzt Design-System-Karten mit einer Einführung in einfacher Sprache und einer Zeile pro Anmeldemethode – Authenticator App, Passkey/Sicherheitsschlüssel, E-Mail-Code, SMS –, jeweils mit einer leicht verständlichen Beschreibung, einer Kennzeichnung für „Aktiv“/„Standard“ und integrierten Aktionen. Im Hintergrund haben sich drei Funktionen geändert:
- Methoden können jederzeit hinzugefügt werden, nicht nur, solange die 2FA noch deaktiviert ist, und jede Registrierungsoberfläche (Profil, Onboarding-Assistent, WP-CLI, der Schlüsselmanager) wird über einen gemeinsamen Aktivierungspfad geleitet.
- Die Standard-Anmeldemethode kann vom Benutzer ausgewählt werden. Jede aktive Methodenzeile enthält die Option „Als Standard festlegen“; die Auswahl wird zunächst beim Login abgefragt. Im Hintergrund handelt es sich hierbei um einen neuen
set_primary_methodAJAX-Endpoint, der anTwo_Factor::set_user_method(), der alle Methoden ablehnt, die der Benutzer nicht tatsächlich aktiviert hat. - Die SMS-Verwaltung wurde in das Profil integriert. Dort kann eine Nummer eingerichtet oder geändert werden, wobei eine geänderte Nummer die verifizierte Nummer erst dann ersetzt, wenn die neue Nummer einen Bestätigungscode bestätigt hat – ein Tippfehler kann den Vorgang nun nicht mehr unterbrechen.
Einzelne Methoden können nun separat entfernt werden, wobei eine deutliche Warnung angezeigt wird, wenn das Entfernen der letzten Methode die 2FA vollständig deaktivieren würde. Bei Neuinstallationen sind standardmäßig alle vier Methoden aktiviert (totp, email, webauthn, sms — SMS ist nutzbar, sobald ein Tarif mit Relay-Funktion verbunden ist); bestehende Websites behalten ihre gespeicherte Auswahl bei. Das Hinzufügen einer zweiten Methode überschreibt zudem nicht mehr die Standardeinstellung des Benutzers und generiert auch nicht mehr stillschweigend vorhandene Recovery Codes neu – beides war beim alten TOTP-Endpoint der Fall.
Was bleibt kostenlos und wofür ist die Business-Version erforderlich?
Ein Sicherheitsschlüssel oder Passkey pro Konto ist in jedem Tarif Free – einschließlich Registrierung, Login auf allen drei Authentifizierungsplattformen, Umbenennung und Löschung sowie der E-Mail-Warnung bei geklonten Schlüsseln. Der Business plan bietet zusätzlich erweiterte Funktionen: mehrere Schlüssel pro Konto, automatische Modellerkennung durch Attestierung sowie E-Mail-Benachrichtigungen zum Lebenszyklus der Schlüssel. Die Unterscheidung wird serverseitig in den Registrierungs-Endpoints durchgesetzt (webauthn_advanced in der Funktionsübersicht), und Registrierungen im Free tier erfordern attestation: 'none' , sodass für eine Funktion, die in der jeweiligen Stufe nicht enthalten ist, niemals eine Einwilligungsabfrage im Browser erscheint. Details zu den Tarifen finden Sie auf der Preisseite.
Wenn Sie Hintergrundinformationen darüber wünschen, wie WebAuthn, Passkeys und Hardware-Schlüssel zusammenhängen, finden Sie die entsprechenden Konzepte im Leitfaden zum Passkey-Login; Informationen zu dem konkreten Schlüssel, den wir entwickeln und mit dem wir Tests durchführen, finden Sie im Bericht zum YubiKey 5C NFC.
Sicherheitskorrekturen, die zusammen mit […] ausgeliefert wurden
Die offizielle Einführung von Hardware-Schlüsseln erforderte eine Überprüfung des gesamten WebAuthn-Prozesses, und im Zuge dieser Überprüfung wurden mehrere Fehlerbehebungen vorgenommen. Der Passwort-Reset-Prozess bindet den Browser nun über ein kurzlebiges, vom Server generiertes Token an die zurückgesetzte Identität – niemals über URL-Parameter, die über Referrer und Protokolle offengelegt werden könnten. Die AJAX-Endpoints für den WebAuthn-Login unterliegen derselben IP-spezifischen Sperrkette wie das Challenge-Formular, wodurch eine Umgehung des Rate Limits verhindert wird, und die Registrierungsoptionen werden pro Benutzer gedrosselt. Der eigenständige CBOR-Decoder lehnt abgeschnittene, unbestimmte, mit Tags versehene und Float-Eingaben mit eindeutigen Fehlermeldungen und einer Begrenzung der Verschachtelungstiefe ab; der EC2-COSE-Pfad überprüft die P-256-Kurve vor der Verwendung.
Zwei Verbesserungen zur Erhöhung der Benutzerfreundlichkeit sind erwähnenswert. Das Berühren eines YubiKeys außerhalb einer aktiven Authentifizierungssitzung führt nicht mehr zu verwirrenden Fehlermeldungen – eingegebene Yubico-OTP-Daten (die lange Zeichenfolge in Kleinbuchstaben, die ein Schlüssel bei versehentlichem Antippen ausgibt) werden erkannt und mit einer entsprechenden Anleitung beantwortet. Außerdem wird bei der Einleitung einer TOTP-Einrichtung das bereits bestätigte Authentifikator-Geheimnis nicht mehr stillschweigend überschrieben; eine Neueinrichtung erfordert nun die explizite Auswahl von „Erneut einrichten“. Außerhalb des 2FA-Subsystems prüft die WAF-Drop-in-Synchronisation nun vor jedem Schreibvorgang für Guard-Regeln, Blocklisten und Direktiven die Schreibbarkeit und wechselt in den Fail-Open-Modus, anstatt PHP-Warnungen auszugeben, die auf schreibgeschützten Dateisystemen die Weiterleitungen des Administrators mit der Meldung „Header bereits gesendet“ unterbrachen.
Strengere Kontrollen und weniger Lärm auf dem Weg hierher
Die Versionsreihe 2.1.23–2.1.32 verdient eine gesonderte Erwähnung, da mehrere dieser Änderungen das alltägliche Verhalten beeinflussen. Seit 2.1.26/2.1.27 hat eine Crawler-Angabe im User-Agent für sich genommen keinerlei Bedeutung: Jede Angabe wird mit vorwärtsbestätigten Reverse-DNS-Einträgen und offiziellen IP-Bereichen abgeglichen; eine zentrale Schutzmaßnahme verschont nur verifizierte Crawler vor jeder automatischen Sperrentscheidung, und Ereignisse, bei denen Anmeldedaten übermittelt werden – wie fehlgeschlagene Logins –, umgehen die Bot-Allowlist vollständig – echte Crawler übermitteln niemals Anmeldedaten. Seit Version 2.1.31 kann sich der Server zudem nicht mehr selbst blockieren: Crawler zum Vorladen des Caches, WP-Cron-Loopbacks und REST-Selbstanfragen kommen von der eigenen öffentlichen Adresse der Website, und eine Multisite im Einsatz hatte ihre eigene IPv6-Adresse wegen „REST API-Missbrauchs“ sieben Tage lang automatisch blockiert. Die automatische Pipeline wird nun für die eigenen Adressen des Servers deaktiviert, und eine Upgrade-Migration hebt bestehende Selbstsperren auf.
Gleichzeitig wurde die Durchsetzung verschärft. Die Eskalationsleiter berücksichtigt nun das Volumen – ein Angreifer, der innerhalb von zehn Sekunden sechzig Regelverstöße auslöst, überspringt mehrere Stufen, anstatt wie bei drei Verstößen die gleichen fünf Minuten zu erhalten. Der „Pre-WordPress Guard“ (Extended Protection) setzt IP-Sperren durch, bevor WordPress geladen wird, und protokolliert jeden blockierten Zugriff, sodass die Eskalationsleiter und die Reports durch die Community auch bei Anfragen funktionieren, die WordPress gar nicht zu Gesicht bekommt. Und Version 2.1.32 hat den Preis für all dies in Form von Leistungseinbußen bezahlt: 36 → 11 Plugin-Abfragen pro anonymer Anfrage, eine Blocklist, die aus einem 8-KB-Header antwortet, anstatt bis zu 1 MB pro Anfrage zu lesen, und ein Sicherheits-Dashboard, dessen TTFB bei einer Log-Tabelle mit 500.000 Zeilen von 920 ms auf 278 ms sank.
So führen Sie ein Update auf Hive 2.1.36 durch
Der integrierte Update-Checker fragt GitHub alle 12 Stunden ab; um die neue Version sofort herunterzuladen, öffnen Sie „Plugins“ → „Nach Updates suchen“. Die Systemvoraussetzungen sind seit Version 2.1.28 unverändert: WordPress 5.9+ und PHP 8.1+. Eine manuelle Migration ist nicht erforderlich – die Upgrade-Routine übernimmt die Schemaanpassung, und für Ed25519 wird lediglich libsodium (seit PHP 7.2 im Lieferumfang enthalten) benötigt. Die Hardware-Abdeckung ist in der WebAuthn-Testmatrix des Repositorys dokumentiert, die jede Veröffentlichung auf einem echten YubiKey 5C NFC unter Windows, Android, iPhone und macOS überprüft.