YubiKey 5C NFC für WordPress-2FA: Technik und Praxis

Der YubiKey 5C NFC ist der Hardware-Schlüssel, mit dem sich unser Team täglich anmeldet, und seit Hive 2.1.36 ist er ein offiziell unterstützter zweiter Faktor auf jeder WordPress-Website, auf der das Plugin läuft. Dieser Leitfaden behandelt die Hardware, die WebAuthn-Ceremony hinter dem Login, die Einstellungen, die Hive dabei schreibt, die Hooks für Entwickler und die neun Fehler, die Ihnen im Betrieb wirklich begegnen.

Das Foto oben ist kein Stockbild: Es zeigt den YubiKey 5C NFC von unserem eigenen Entwicklungsplatz, das Referenzgerät hinter jedem Hive-Release. Alle Versionsnummern und Standardwerte unten stammen aus Hive 2.1.57, veröffentlicht am 15.09.2026.

Was ist der YubiKey 5C NFC?

Der YubiKey 5C NFC ist ein Hardware-Authenticator von Yubico. Er hält kryptografische Schlüssel in einem Secure Element, signiert Login-Challenges auf Berührung und gibt den privaten Schlüssel nie an den Rechner weiter. Keine Batterie, kein Display, keine Netzwerkverbindung. Er steckt in USB-C oder wird an ein NFC-fähiges Telefon gehalten, genau die Kombination, die eine WordPress-Administratorin braucht: Kabel am Schreibtisch, Antippen unterwegs.

Anschlüsse	USB-C und NFC (Antippen unter Android und iOS)
Authentifizierungsprotokolle	WebAuthn / FIDO2 (CTAP 1, 2 und 2.1), U2F, PIV-Smartcard, Yubico OTP, OATH-HOTP/TOTP, OpenPGP, statische Passwörter
Passkey-Kapazität	25 auffindbare Credentials; 100 ab Firmware 5.7
Signaturalgorithmen	ES256, RS256; Ed25519 (EdDSA) seit Firmware 5.2.3
Bauform	IP68 wasser- und staubdicht, bruchfest, ohne Batterie, ohne bewegliche Teile; gefertigt in Schweden

Die vollständigen technischen Daten stehen auf der offiziellen Yubico-Produktseite; die Ed25519-Geschichte beginnt mit den Release Notes zu Firmware 5.2.3. Ein praktischer Hinweis zur Kapazität: Die Grenze von 25 gilt nur für auffindbare Credentials, also Passkeys, die auf dem Schlüssel selbst liegen. Ein über Hive eingerichteter zweiter Faktor für WordPress belegt keinen dieser Plätze, warum, steht weiter unten.

Warum ein Hardware-Schlüssel Einmalcodes schlägt

Jeder codebasierte zweite Faktor, ob Authenticator-App, E-Mail oder SMS, teilt eine Schwäche: Der Code lässt sich auf der falschen Seite eintippen. Eine Phishing-Seite, die Ihren echten Login weiterreicht, gibt einen TOTP-Code innerhalb seines 30-Sekunden-Fensters weiter, und Angreifer automatisieren das mit fertigen Reverse-Proxy-Baukästen. Ein FIDO2-Schlüssel ist gegen diese Angriffsklasse konstruktiv immun: Die Signatur, die er erzeugt, ist an die Origin gebunden, die sie angefordert hat. Ein Credential, das für Ihre echte Domain registriert wurde, liefert auf einer nachgebauten Domain nichts Verwertbares. Es gibt keinen Code zu stehlen, weil es keinen Code gibt.

Zweiter Faktor	Phishing-resistent	Offline nutzbar	Typischer Ausfall
Authenticator-App (TOTP)	Nein, Codes lassen sich weiterreichen	Ja	Telefon verloren oder ohne Backup zurückgesetzt
E-Mail-Code	Nein	Nein	Postfach kompromittiert oder Mail verzögert
SMS-Code	Nein	Nein	SIM-Swap, Zustellprobleme
Hardware-Schlüssel (FIDO2)	Ja, Origin-gebundene Signaturen	Ja	Schlüssel verloren, ohne Zweitschlüssel

Der ehrliche Vorbehalt steht in der letzten Zelle: Ein verlorener Schlüssel ohne Fallback sperrt Sie aus. Die praktische Antwort ist die, die auch Yubico gibt. Registrieren Sie zwei Schlüssel und lagern Sie einen außer Haus. Hive unterstützt das mit einem Key-Manager für ein Primär- und ein Backup-Credential, dazu Recovery Codes und jede weitere 2FA-Methode als Rückfallebene. Unser Leitfaden zur WordPress-2FA vergleicht alle vier Methoden ausführlicher.

Wie die WebAuthn-Ceremony beim Login abläuft

Wer den Ablauf verstanden hat, versteht auch die meisten Fehlermeldungen, deshalb sind diese 400 Wörter gut angelegt. WebAuthn teilt die Authentifizierung in zwei Ceremonies: Registration, bei der der Schlüssel ein neues Schlüsselpaar erzeugt, und Assertion, bei der er eine Challenge signiert und damit beweist, dass er die private Hälfte noch besitzt.

Die Registration bindet ein Schlüsselpaar an eine Domain

Beim Registrieren schickt der Server eine 32 Byte lange Zufalls-Challenge, eine Relying-Party-ID (den nackten Hostnamen, etwa example.com) und eine Liste zulässiger Signaturalgorithmen. Der Browser ergänzt die Origin, die er gerade anzeigt, fasst beides in clientDataJSON zusammen und gibt die Anfrage an den Authenticator weiter. Der Schlüssel erzeugt ein frisches Schlüsselpaar für genau diese Relying-Party-ID, behält den privaten Schlüssel im Secure Element und liefert den öffentlichen Schlüssel plus eine Credential-ID zurück. Der Server speichert beides. Nichts Geheimes verlässt je das Gerät, und derselbe Schlüssel erzeugt auf jeder Website ein völlig anderes Schlüsselpaar. Zwei Websites können ihre Nutzer über das Credential also nicht miteinander in Verbindung bringen.

Die Assertion beweist Besitz, ohne etwas preiszugeben

Beim Login schickt der Server eine neue Zufalls-Challenge und die Liste der Credential-IDs, die er für dieses Konto kennt. Der Schlüssel signiert seine Authenticator-Daten zusammen mit dem SHA-256-Hash von clientDataJSON. Der Server prüft diese Signatur gegen den gespeicherten öffentlichen Schlüssel und kontrolliert vier Dinge: Die Challenge ist die, die er ausgegeben hat, die Origin steht auf seiner Liste, der Hash der Relying-Party-ID passt, und das User-Presence-Flag ist gesetzt. Auf jeder anderen Domain ist die Signatur wertlos, weil die Origin im signierten Payload steckt. Genau daran scheitert ein Phishing-Proxy: Der Angreifer kann die Bytes weiterreichen, aber die Signatur trägt seine eigene Domain, und der echte Server weist sie ab.

Wozu die Berührung dient

Die Berührung der goldenen Scheibe setzt das User-Presence-Flag. Sie belegt, dass ein Mensch physisch am Schlüssel steht und nicht Schadsoftware still den USB-Stack bedient. Eine Identitätsprüfung ist sie nicht. Die Identitätsprüfung (das UV-Flag) ist ein eigener Schritt, der eine FIDO2-PIN oder einen Fingerabdruck verlangt, und Hive fordert sie standardmäßig bewusst nicht an. Die Begründung steht im nächsten Abschnitt.

Wie Hive WebAuthn in WordPress umsetzt

Hive bringt einen eigenständigen WebAuthn-Level-2-Verifier in class-two-factor-webauthn.php mit (1.325 Zeilen), ohne Composer-Abhängigkeit. Er liest CBOR-Attestation-Objekte und COSE-Schlüssel mit dem OpenSSL der PHP-Standardbibliothek, was das ausgelieferte Plugin schlank hält. Der Kompromiss steht im Klassen-Header: Abgedeckt ist der Teil, den der zweite Faktor braucht, Attestation-Zertifikatsketten gegen den FIDO Metadata Service prüft er nicht.

Das ist eine bewusste Entscheidung, keine Lücke. Attestation sagt nur, welches Schlüsselmodell im Spiel war. Die Enrolment-Ceremony läuft ohnehin erst nach einer erfolgreichen Passwortprüfung, eine verifizierte Kette bringt dem zweiten Faktor also keine zusätzliche Sicherheit. Hive prüft Packed-Attestation-Statements nach bestem Wissen und nutzt das Ergebnis für genau eine Sache: die Modellbezeichnung im Key-Manager.

Welche Algorithmen bei der Registration angeboten werden

Hive bietet drei COSE-Algorithmen an, den stärksten zuerst: Ed25519 (-8), ES256 (-7) und RS256 (-257). Ed25519 landet nur dann auf der Liste, wenn sodium_crypto_sign_verify_detached() auf dem Server existiert. Ein Credential, das heute mit einem Algorithmus registriert wird, den der Server morgen nicht prüfen kann, wäre eine stille Aussperrung. Ab PHP 7.2 gehört libsodium zum Kern, die meisten Hoster erfüllen die Bedingung also. Ein YubiKey ab Firmware 5.2.3 greift sich Ed25519 aus dieser Liste, und Sie können das auf Ihrer eigenen Installation nachsehen: Das gespeicherte Credential meldet COSE-Algorithmus −8.

Warum userVerification auf discouraged bleibt

Hive setzt in beiden Ceremonies userVerification: 'discouraged', den Wert, den Yubico für den reinen Zweitfaktor-Einsatz empfiehlt. Ein frischer YubiKey hat keine FIDO2-PIN, und preferred oder required würde den Nutzer mitten im Login in die PIN-Einrichtung schicken. Plattform-Authenticator wie Windows Hello oder Touch ID prüfen die Identität ohnehin, unabhängig von diesem Wert. Websites, die eine strikte Prüfung wollen, heben den Wert über den Filter reportedip_hive_webauthn_user_verification an; der Server erzwingt das UV-Flag dann bei jeder Ceremony selbst, statt dem Client zu glauben.

Warum die Registrierung keinen Passkey-Platz verbraucht

Die Registration fordert residentKey: 'discouraged' an. Ein auffindbares Credential, also ein Passkey auf dem Schlüssel selbst, würde einen der 25 Plätze des YubiKeys belegen und mitten im Setup eine FIDO2-PIN erzwingen, ohne dem zweiten Faktor etwas zu bringen: Der Login-Ablauf liefert immer allowCredentials mit, der Schlüssel muss also nie selbst etwas finden. Das Credential liegt in den User-Metadaten der Website, der Schlüssel speichert nichts, und ein einzelner YubiKey kann auf diesem Weg beliebig viele WordPress-Sites bedienen. Früher angelegte auffindbare Credentials funktionieren weiter.

Challenges und die Bindung an das Konto

Challenges sind 32 Zufallsbytes, liegen 300 Sekunden in einem Transient und werden in dem Moment gelöscht, in dem sie eingelöst werden. Eine wiederholte Antwort scheitert also beim zweiten Versuch. Während des Logins ist der Nutzer noch nicht angemeldet, ein normaler WordPress-Nonce fällt damit aus. Hive bindet die Identität über das httpOnly-Cookie reportedip_2fa_token, das der Authenticate-Filter nach der Passwortprüfung setzt, mit 900 Sekunden Laufzeit. Das JavaScript liest dieses Token nie, damit bleibt es für Cross-Site-Scripting unerreichbar. Oberflächen ohne dieses Cookie, allen voran das Passwort-Reset-Gate, bekommen stattdessen ein eigens erzeugtes Einweg-Token. Keines der beiden Token ersetzt die Signatur: Wer es vorlegt, bekommt nur Zugang zur Ceremony.

Die drei Challenge-Oberflächen

Ein Security Key funktioniert an allen drei Stellen, an denen WordPress einen zweiten Faktor verlangen kann: an der Challenge von wp-login.php, an der WooCommerce-Challenge im Shop-Frontend und am Passwort-Reset-Gate. Das Reset-Gate wiegt schwerer, als es aussieht. Eine Website, die den Login absichert, das Zurücksetzen des Passworts aber mit einem reinen E-Mail-Faktor offen lässt, hat den Angriff verschoben statt beseitigt. Genau deshalb schließt die Option reportedip_hive_2fa_password_reset_excluded_methods dort standardmäßig email aus.

Einen YubiKey mit Hive in WordPress einrichten

Der kostenlose Tarif enthält einen Security Key oder Passkey pro Konto, nutzbar auf allen drei Oberflächen. Die Einrichtung dauert etwa zwei Minuten.

Installieren Sie ReportedIP Hive (2.1.36 oder neuer) und schalten Sie die Zwei-Faktor-Authentifizierung ein. Seit 2.1.54 sitzt dieser Schalter im einseitigen Quickstart, und alle vier Methoden sind standardmäßig erlaubt.
Öffnen Sie Ihr WordPress-Profil und suchen Sie die Karte Security keys & passkeys.
Vergeben Sie zuerst einen Namen (YubiKey Büro hilft später mehr als Schlüssel 1, wenn Sie entscheiden müssen, welches Credential Sie widerrufen), und wählen Sie dann Security key (USB / NFC). Diese Schaltfläche sendet den Hint security-key, womit Chrome und Edge direkt den Hardware-Dialog öffnen, statt zuerst einen QR-Code fürs Telefon anzubieten.
Stecken Sie den Schlüssel ein und berühren Sie die goldene Scheibe, oder halten Sie ihn flach an die Oberseite Ihres Telefons, wenn Sie NFC nutzen.
Registrieren Sie einen zweiten Schlüssel als Backup, oder erzeugen Sie Recovery Codes als Rückfallebene.

Die zweite Schaltfläche dieser Karte, This device (Face ID / Windows Hello), sendet den Hint client-device und registriert stattdessen den Plattform-Authenticator. Beide landen in derselben Credential-Liste, nur Modellbezeichnung und Transport unterscheiden sich.

Ein Detail, das ein Support-Ticket spart: Die Registrierung ist auf zehn Options-Anfragen pro Nutzer und zehn Minuten begrenzt. Wer das Enrolment auf einem Staging-System mehrfach durchprobiert, läuft in diese Grenze, und die Meldung („Too many registration attempts”) liest sich wie ein Fehler, wenn man die Regel nicht kennt.

Welche Website-Einstellungen Security Keys steuern

Die meisten Websites fassen diese Werte nie an, aber wer sie kennt, macht aus einem Enforcement-Rollout einen Plan statt eines Versuchs. Alle stehen seit 2.1.56 auf der Protection-Seite und lassen sich über MainWP oder den Cloud-Fleet-Transport auch aus der Ferne setzen.

Option	Standard	Wirkung
`2fa_allowed_methods`	totp, email, webauthn, sms	Welche Methoden Nutzer überhaupt einrichten dürfen. Eine hier entfernte Methode wird beim Enrolment serverseitig abgelehnt. Damit kann kein Schlüssel registriert werden, während die Methode aus ist, um dann still zu funktionieren, sobald sie wieder an ist.
`2fa_enforce_roles`	administrator	Rollen, die einen zweiten Faktor haben müssen.
`2fa_enforce_grace_days`	7	Tage, die sich ein betroffener Nutzer anmelden darf, bevor die Einrichtung Pflicht wird.
`2fa_max_skips`	3	Wie oft die Einrichtungsaufforderung nach Ablauf der Frist noch verschoben werden darf.
`2fa_enforce_action`	enroll	Was passiert, wenn Frist und Verschiebungen aufgebraucht sind. Steht der Wert auf `lockout`, wird der Login abgewiesen, außer bei Administratoren und Super-Admins. Die werden nie ausgesperrt, damit eine Website nie ohne nutzbares Konto dasteht.
`2fa_trusted_device_days`	30	Wie lange ein Gerät als vertrauenswürdig gilt, bevor der zweite Faktor erneut abgefragt wird.
`2fa_ip_allowlist`	leer	IPs oder CIDR-Blöcke, die die Abfrage überspringen (IPv4 und IPv6). Nützlich für einen Büro-Bereich, riskant bei allem Dynamischen.
`2fa_enforce_super_admins`	true	Super-Admins im Multisite brauchen immer einen zweiten Faktor.

Fehlversuche eskalieren pro IP auf einer festen Leiter, die sich alle 2FA-Methoden teilen: 3 Fehlversuche kosten 30 Sekunden, 5 kosten 5 Minuten, 10 kosten 30 Minuten, 15 kosten eine Stunde. Die WebAuthn-Endpoints prüfen diese Leiter, bevor sie eine Challenge ausgeben. Skriptgesteuerte Versuche gegen den Assertion-Endpoint laufen also gegen dieselbe Wand wie geskriptetes Code-Raten.

Was der Signature Counter aufdeckt

Jeder Authenticator führt einen Zähler, erhöht ihn bei jeder Assertion und legt ihn in die signierten Daten. Der Server merkt sich den zuletzt gesehenen Wert. Kommt eine Assertion mit einem Zähler an, der nicht weitergelaufen ist, wurde der Schlüssel geklont oder sein Zustand zurückgerollt. Hive weist diesen Login ab, schreibt ein Ereignis 2fa_webauthn_counter_regression mit Schweregrad high samt User-ID, Credential-ID und beiden Zählerständen und feuert einen Action-Hook, der dem Kontoinhaber eine Mail schickt. Diese Warnung ist in jedem Tarif enthalten.

Eine Ausnahme ist eingebaut: Viele Plattform-Passkeys (iCloud-Schlüsselbund, Google Password Manager) melden konstruktionsbedingt dauerhaft den Zähler null, weil ein synchronisiertes Credential kein einzelnes Gerät hat, auf dem gezählt werden könnte. Hive wertet gespeicherte und gemeldete Null als normal und meldet nur einen echten Rückfall. Einen YubiKey zu klonen ist kein praktikabler Angriff, der private Schlüssel verlässt das Secure Element nie, aber die Prüfung kostet nichts und fängt den Fall ab, dass ein Backup eines emulierten Authenticators zurückgespielt wird.

Planen Sie den Schlüssel ein, den Sie irgendwann verlieren

Der Verlust eines Schlüssels ist der einzige realistische Ausfall dieses Aufbaus. Planen Sie ihn, bevor er eintritt. Es gibt vier Rückfallebenen, nach Komfort absteigend.

Ein zweiter registrierter Schlüssel. Der bequeme Weg, und der Grund, warum der Business-Tarif mehrere Credentials pro Konto erlaubt. Lagern Sie den Zweitschlüssel räumlich getrennt vom ersten.
Recovery Codes. Einmal nutzbare Codes, die beim Setup entstehen. Drucken Sie sie aus oder legen Sie sie in einen Passwortmanager, nie in dasselbe Browserprofil, das Sie gerade absichern.
Eine zweite Methode. TOTP als paralleler Faktor kostet nichts und überlebt einen verlorenen Schlüssel. Es ist weniger phishing-resistent, ein Kompromiss, den Sie bewusst eingehen.
WP-CLI. Eine Server-Administratorin führt wp reportedip 2fa reset <user_id> aus. Der Befehl entfernt alle 2FA-Daten des Kontos und schreibt eine Warnung ins Aktivitätsprotokoll, damit das Zurücksetzen nachvollziehbar bleibt.

Eine selbstverschuldete Aussperrung verhindert Hive aktiv: das Löschen des letzten verbliebenen Schlüssels, wenn WebAuthn Ihre einzige aktive Methode ist und Ihre Rolle unter die Pflicht fällt. Das Löschen wird mit dem Hinweis abgelehnt, zuerst eine weitere Methode einzurichten. Außerhalb dieses Falls macht das Entfernen eines Credentials es sofort ungültig, und genau das tun Sie in der Sekunde, in der ein Schlüssel abhandenkommt.

Multisite, Subdomains, Staging: wo die Relying-Party-ID zubeißt

Die Relying-Party-ID leitet sich aus dem Host von home_url() ab. Ein Credential gilt nur für diese ID, woraus sich drei Situationen ergeben, die man besser vor dem Rollout kennt als danach.

Multisite mit Subdomains. Ein auf shop.example.com registrierter Schlüssel funktioniert nicht auf blog.example.com. Über den Filter reportedip_hive_webauthn_rp_id gibt eine Netzwerk-Administratorin die registrierbare Elterndomain zurück (example.com), damit ein Enrolment das ganze Netzwerk abdeckt. Setzen Sie ihn einmal, vor dem Rollout: Eine spätere Änderung der RP-ID macht jedes unter dem alten Wert registrierte Credential wertlos.
Dashboard auf einem anderen Host. Installationen, bei denen sich site_url() und home_url() unterscheiden, sind abgedeckt, weil beide Hosts in die Liste der akzeptierten Origins wandern. Für exotischere Fälle gibt es den Filter reportedip_hive_webauthn_allowed_origins.
Staging-Kopien. Eine aus der Produktion geklonte Datenbank trägt Produktions-Credentials, deren RP-ID nicht zum Staging-Host passt. Die Assertion scheitert an Origin oder RP-ID. Das ist korrektes Verhalten, kein Fehler. Registrieren Sie auf dem Staging einen eigenen Schlüssel, oder halten Sie dort eine andere Methode bereit.

Eine verwandte Bedingung, über die lokale Setups stolpern: WebAuthn braucht einen sicheren Kontext. Also HTTPS, oder http://localhost. Ein Staging-System auf reinem HTTP unter einer LAN-Adresse zeigt den Schlüsseldialog nie, und der Browser meldet das als Sicherheitsfehler statt als fehlende Funktion.

Neun Fehler, die Ihnen wirklich begegnen, und was sie bedeuten

Browser melden WebAuthn-Fehler bewusst unscharf, weil genaue Fehler etwas über registrierte Credentials verraten würden. Hive übersetzt die Browser-Exceptions in handlungsfähige Texte, und die Tabelle unten führt sie zurück auf ihre Ursachen.

Meldung oder Exception	Ursache	Lösung
`NotAllowedError` („request timed out or was cancelled”)	Die Ceremony lief über 120 Sekunden, der Dialog wurde weggeklickt, oder der Schlüssel wurde nie berührt. Der häufigste NFC-Fall: Der Schlüssel lag an der falschen Stelle des Telefons.	Erneut versuchen, am Telefon den Schlüssel flach an die Antenne halten, meist im oberen Drittel der Rückseite.
`SecurityError`	Die Origin der Seite passt nicht zur Relying-Party-ID des Credentials. Staging-Klon, Subdomain-Wechsel, oder eine Website, die unter www und ohne www erreichbar ist.	Auf dem kanonischen Host anmelden, oder den RP-ID-Filter vor dem Rollout setzen.
`InvalidStateError` bei der Registration	Dieser Schlüssel ist auf diesem Konto bereits registriert. Der Server schickt die vorhandenen Credential-IDs in `excludeCredentials`, und der Authenticator lehnt das Duplikat ab.	Nichts zu tun. Nehmen Sie den bereits registrierten Schlüssel, oder registrieren Sie einen anderen.
`AbortError`	Eine andere WebAuthn-Anfrage hat übernommen, oder die Seite wechselte mitten in der Ceremony.	Auf einer frisch geladenen Challenge-Seite erneut versuchen.
„Challenge expired, please start again”	Zwischen dem Öffnen des Dialogs und der Antwort lagen mehr als 300 Sekunden.	Die Ceremony neu starten.
„Signature counter anomaly”	Der Zähler ist nicht weitergelaufen. Geklonter oder zurückgerollter Authenticator, oder ein zurückgespieltes Emulator-Image.	Als Vorfall behandeln: Credential widerrufen, neuen Schlüssel registrieren, Aktivitätsprotokoll prüfen.
„Too many registration attempts”	Zehn Enrolment-Ceremonies innerhalb von zehn Minuten.	Ein paar Minuten warten. Beim Testen ist das zu erwarten.
„Security keys are not available on this site”	Die WebAuthn-Methode ist in den erlaubten Methoden abgeschaltet.	Auf der Protection-Seite wieder einschalten.
„Multiple security keys per account require the Business plan”	Es wurde ein zweites Credential in einem Tarif versucht, der eines enthält.	Recovery Codes oder eine zweite Methode als Backup nutzen, oder die Tarife auf der Preisseite vergleichen.

Ein Symptom ist gar kein Fehler: eine Folge zufälliger Zeichen im Passwortfeld, die meist mit cccc beginnt. Das ist Yubico OTP. Der Schlüssel hat ein Einmalpasswort getippt, weil er berührt wurde, während ein Textfeld den Fokus hatte, außerhalb jeder WebAuthn-Ceremony. Feld leeren und die Ceremony über ihre eigene Schaltfläche starten.

NFC am Telefon: was funktioniert und was nicht

NFC sorgt für die meiste Verwirrung im ganzen Aufbau, weil der Fehlerfall Stille ist statt einer Meldung. Drei Dinge entscheiden, ob das Antippen klappt.

Position. Die Antenne sitzt nicht in der Mitte des Telefons. Bei den meisten Android-Geräten liegt sie im oberen Drittel der Rückseite, bei iPhones an der Oberkante. Halten Sie den Schlüssel ein bis zwei Sekunden flach und ruhig dagegen, statt ihn hin und her zu bewegen.
Hüllen. Dünner Kunststoff stört nicht. Metallplatten für Magnethalterungen, dicke Akkuhüllen und manche Geldbörsen-Cases blockieren das Feld vollständig.
Zeit. Telefon wecken, Schlüssel suchen, richtig positionieren, das dauert regelmäßig länger als die 60 Sekunden, die WebAuthn standardmäßig vorsieht. Hive hebt das Ceremony-Timeout genau deshalb auf 120 Sekunden an, und dieser Wert ist eine Konstante in der WebAuthn-Klasse, keine Einstellung.

Unter iOS zeigt der Browser ein System-Sheet, das Sie bittet, den Schlüssel an die Oberkante des Geräts zu halten, bevor die Ceremony startet. Unter Android hängt die Aufforderung von der Chrome-Version ab, und wenn NFC in den Systemeinstellungen aus ist, bietet der Browser still den QR-Code-Weg über ein zweites Gerät an. NFC in den Schnelleinstellungen einzuschalten ist die Lösung, an die niemand denkt.

Hooks, Filter und WP-CLI für Entwickler

Die WebAuthn-Implementierung stellt drei Filter und drei Action-Hooks bereit. Die Filter formen die Ceremony, über die Actions hängen Sie Schlüssel-Ereignisse in Ihr eigenes Auditing oder Alerting.

Hook	Typ	Zweck
`reportedip_hive_webauthn_rp_id`	Filter	Gibt bei Subdomain-Multisite die registrierbare Elterndomain zurück. Einmal setzen, vor dem Rollout.
`reportedip_hive_webauthn_allowed_origins`	Filter	Ergänzt akzeptierte Origins bei Domain-Mapping oder getrennten Hosts.
`reportedip_hive_webauthn_user_verification`	Filter	Hebt den Wert auf `preferred` oder `required` an. Das UV-Flag wird dann serverseitig bei jeder Ceremony erzwungen.
`reportedip_hive_2fa_webauthn_key_registered`	Action	Feuert mit User-ID und Schlüsselnamen, nachdem ein Credential gespeichert wurde.
`reportedip_hive_2fa_webauthn_key_removed`	Action	Feuert mit User-ID und Schlüsselnamen, nachdem ein Credential gelöscht wurde.
`reportedip_hive_2fa_webauthn_counter_regression`	Action	Feuert mit User-ID, Credential-ID und Schlüsselnamen, wenn eine Assertion wegen eines stehen gebliebenen Zählers abgelehnt wird.

Auf der Kommandozeile listet wp reportedip 2fa status jeden Nutzer mit seinen eingerichteten Methoden und der Angabe, ob die Pflicht greift. Das ist der schnellste Weg, einen Rollout zu prüfen. wp reportedip 2fa enforce --role=editor nimmt eine Rolle in die Pflichtliste auf, --remove nimmt sie wieder heraus. Der Befehl, der eine Warnung verdient, ist wp reportedip 2fa enable --method=webauthn: Die Methode für einen Nutzer zu setzen, der kein Credential registriert hat, ist keine Einrichtung, sondern eine Aussperrung. Der Befehl verweigert das deshalb, solange Sie nicht --force mitgeben.

Welche Security Keys funktionieren mit WordPress und Hive?

Jeder FIDO2/WebAuthn-Authenticator funktioniert. Getestet wird mit der YubiKey-5-Serie, derselbe Ablauf nimmt aber auch Modelle der Reihe Security Key by Yubico an, FIDO2-Schlüssel anderer Hersteller und Plattform-Passkeys wie Windows Hello, iCloud-Schlüsselbund, Google Password Manager, 1Password oder Bitwarden.

Im Business-Tarif benennt der Key-Manager die Hardware, statt eine allgemeine Bezeichnung zu zeigen. Dahinter steckt eine statische AAGUID-Registry im Plugin: 90 Authenticator-IDs, die auf 32 Modellbezeichnungen zeigen, die Yubico-Einträge aus dem FIDO Alliance Metadata Service, die Plattform-Anbieter aus der AAGUID-Liste der Community. Die Abfrage dient nur der Anzeige und fließt nie in eine Policy-Entscheidung ein. Eine unbekannte AAGUID fällt schlicht auf die allgemeine Bezeichnung zurück. Es gibt keinen Abruf zur Laufzeit und keinen Cron dahinter, die Liste wird aktualisiert, wenn neue Hardware erscheint.

Wenn Sie schon Passkeys nutzen, erklärt der Leitfaden zum Passkey-Login, wie die beiden zusammenhängen. Kurz gesagt: Ein Hardware-Schlüssel ist ein Passkey, den Sie in der Hand halten, niemandem leihen und in einen Safe legen können.

Wie wir den YubiKey 5C NFC nutzen und testen

Wir haben dieses Modell nicht für den Artikel ausgesucht. Den Artikel gibt es, weil wir dieses Modell benutzen. Der YubiKey 5C NFC sichert unsere eigenen Konten, und derselbe physische Schlüssel ist das Freigabe-Gate für Hives WebAuthn-Unterstützung: Keine Version, die den 2FA-Pfad berührt, geht raus, bevor der Schlüssel Enrolment und Login auf einem Staging-System über fünf Kombinationen aus Plattform und Transport geschafft hat. Windows 11 mit Chrome und mit Edge über USB-C, Android Chrome und iPhone Safari über NFC, und macOS Safari über USB-C. Die Matrix prüft außerdem, dass sich ein zweiter Schlüssel sauber registriert, dass ein fremder Schlüssel abgelehnt wird, und dass eine abgebrochene und neu gestartete Ceremony ohne Reload wieder funktioniert.

Automatisiert läuft das bei jedem Build in der CI über Playwright und den virtuellen Authenticator von Chromium. Das fängt Protokoll-Regressionen schnell und billig ab und ist blind für alles Körperliche: NFC-Positionierung, echte Signature Counter, das Gefühl für 120 Sekunden Timeout, und den Fall der versehentlichen Berührung, bei dem ein YubiKey sein Einmalpasswort in ein Formular tippt, weil ihn jemand im Vorbeigehen gestreift hat. Diese Lücke zwischen Emulation und Hardware ist der Grund, warum ein echter Schlüssel im Release-Prozess bleibt.

Ein Rollout-Plan für ein Team

Ein ganzes Redaktionsteam auf Hardware-Schlüssel umzustellen scheitert auf vorhersehbare Weise. Diese Reihenfolge vermeidet das meiste davon.

Kaufen Sie zwei Schlüssel pro privilegiertem Konto. Ein Rollout mit einem Schlüssel pro Person erzeugt drei Monate später eine Support-Schlange, wenn der erste durch die Waschmaschine gegangen ist.
Richten Sie Ihr eigenes Konto zuerst ein und melden Sie sich vollständig ab. Prüfen Sie den Login in einem privaten Fenster, bevor Sie fremde Konten anfassen.
Nehmen Sie eine Rolle nach der anderen in die Pflicht, beginnend mit den Administratoren. Die Standardfrist von 7 Tagen plus 3 Verschiebungen gibt den Leuten zwei echte Gelegenheiten, sich ohne Ticket einzurichten.
Halten Sie während des Rollouts eine Methode ohne WebAuthn aktiv. TOTP kostet nichts und verhindert das eine Szenario, das dem ganzen Projekt das Vertrauen entzieht: eine Redakteurin, die kurz vor Redaktionsschluss ausgesperrt ist.
Prüfen Sie mit wp reportedip 2fa status, bevor Sie 2fa_enforce_action auf lockout stellen. Der Befehl zeigt, wem noch eine Methode fehlt.
Schreiben Sie auf, wo die Backup-Schlüssel liegen. Ein Zweitschlüssel, den niemand findet, ist kein Backup.

Häufige Fragen

Was passiert, wenn ich meinen YubiKey verliere?

Sie melden sich mit Ihrem Backup an: einem zweiten registrierten Schlüssel, Recovery Codes, oder einer anderen aktiven 2FA-Methode. Danach entfernen Sie den verlorenen Schlüssel aus Ihrem Profil, was sein Credential sofort ungültig macht. Gibt es keine Rückfallebene, setzt eine Website-Administratorin die 2FA mit wp reportedip 2fa reset <user_id> zurück, und dieses Zurücksetzen steht im Aktivitätsprotokoll.

Funktioniert der YubiKey 5C NFC mit meinem Telefon?

Ja. Unter Android und auf dem iPhone halten Sie den Schlüssel flach an die NFC-Antenne, meist im oberen Drittel der Rückseite oder an der Oberkante, sobald der Browser danach fragt. Hives Ceremony-Timeout von 120 Sekunden gibt es genau deshalb, weil das Finden der Position einen Moment dauert. Dicke Hüllen und Metallrückseiten blockieren das Feld.

Brauche ich einen bezahlten Tarif für einen YubiKey mit Hive?

Nein. Ein Security Key oder Passkey pro Konto ist in jedem Tarif enthalten, samt Login auf allen drei Oberflächen, Umbenennen und Löschen, und der Warnmail bei geklontem Schlüssel. Business ergänzt mehrere Schlüssel pro Konto, die automatische Modellerkennung und die Meldungen zu Schlüssel-Ereignissen.

Verbraucht eine WordPress-Site einen der 25 Passkey-Plätze?

Nein. Hive registriert ein nicht auffindbares Credential, der Schlüssel speichert also nichts und die Platzzahl bleibt unberührt. Ein YubiKey kann auf diesem Weg beliebig viele WordPress-Sites absichern.

Funktioniert mein Schlüssel auf einer Staging-Kopie?

Nicht mit Credentials, die aus der Produktion geklont wurden. Ein Credential hängt an der Relying-Party-ID, die aus dem Host der Website stammt, eine Staging-Domain lehnt es also mit einem Origin- oder RP-ID-Fehler ab. Registrieren Sie dort einen eigenen Schlüssel, oder lassen Sie eine andere 2FA-Methode aktiv.

Muss ich eine FIDO2-PIN setzen?

Für den Einsatz als zweiter Faktor nicht. Hive fordert userVerification: 'discouraged' an, ein frischer Schlüssel löst beim Login also nie eine PIN-Einrichtung aus. Websites, bei denen der Schlüssel selbst die Identität prüfen soll, heben die Vorgabe über den Filter reportedip_hive_webauthn_user_verification an.

Ist ein Hardware-Schlüssel besser als ein Passkey im Passwortmanager?

Beide sind phishing-resistent. Der Unterschied liegt in der Verwahrung: Ein synchronisierter Passkey ist so sicher wie das Konto, über das er synchronisiert wird, während der private Schlüssel einer Hardware das Gerät physisch nicht verlassen kann. Für ein WordPress-Administratorkonto, ein Ziel, das gezielte Angriffe anzieht, nutzen wir Hardware-Schlüssel und halten einen synchronisierten Passkey als bequeme Rückfallebene.

Kann ich einen Schlüssel für mehrere WordPress-Sites nutzen?

Ja, und es gibt keine praktische Grenze. Jede Website erzeugt ihr eigenes Schlüsselpaar für ihre eigene Domain, und keines davon belegt Speicher auf dem Schlüssel.

YubiKey 5C NFC für die WordPress-2FA: Einrichtung, Technik, Fehlerbehebung