Ein gestohlenes Passwort allein darf nicht reichen, um in WordPress einzuloggen. Zwei-Faktor-Authentifizierung (2FA) und Passkeys sind die wirksamste Einzelmassnahme gegen Account-Übernahmen.
Optionen im Überblick
| Verfahren | Sicherheit | Phishing-resistent | Bemerkung |
|---|---|---|---|
| E-Mail-Code | mittel | nein | Nur wenn das Postfach selbst gut gesichert ist |
| TOTP (Authenticator-App) | gut | nein | Standard, breit unterstützt |
| Hardware-Key (FIDO2/WebAuthn) | sehr gut | ja | z. B. |
| YubiKey | Passkeys | sehr gut | ja | Gerätegebunden oder synchronisiert, oft passwortlos |
Phishing-resistente Verfahren (WebAuthn/Passkeys) binden die Anmeldung an die echte Domain. Eine gefälschte Login-Seite kann sie nicht abgreifen.
Umsetzung
- Two-Factor (Plugin des WordPress-Core-Teams): TOTP, E-Mail, Backup-Codes, FIDO/U2F; schlank und ohne Zusatzfunktionen.
- Passkey-Plugins auf Basis von WebAuthn. Vor dem Einsatz Pflegezustand, Bewertungen und Kompatibilität mit dem eigenen Login-Flow prüfen.
- Security-Suiten (Wordfence, Solid Security u. a.) bringen 2FA mit, sinnvoll, wenn ohnehin im Einsatz.
- SSO: Für Teams kann ein Login über einen Identity Provider (Microsoft Entra ID, Google Workspace, Okta) mit dort erzwungener MFA die beste Lösung sein. Zentrale Sperrung beim Austritt inklusive.
Richtlinien
- 2FA für alle Rollen ab Redakteur erzwingen, nicht nur anbieten.
- Backup-Codes sicher ablegen (Passwortmanager) und einen Notfallprozess definieren.
- Nach Aktivierung bestehende Sessions beenden:
wp user session destroy --all --all-users. - 2FA schützt nicht vor Session-Hijacking. Gestohlene Login-Cookies (z. B. durch Infostealer-Malware auf Admin-Rechnern) umgehen jeden zweiten Faktor. Darum Salts nach Vorfällen erneuern und Admin-Rechner sauber halten.
Nicht vergessen: andere Zugänge
Die Website ist nur so sicher wie der schwächste Zugang. MFA gehört auch auf das Hosting-Panel, den Domain-Registrar, DNS (z. B. Cloudflare), Git-Hosting, SFTP/SSH (Key-basiert) und das E-Mail-Postfach, über das Passwort-Resets laufen.
Application Passwords
REST-API-Zugriffe mit Application Passwords umgehen 2FA by design. Darum pro Integration ein eigenes Passwort anlegen, nur bei Bedarf aktivieren und regelmässig prüfen, welche noch genutzt werden. Wer sie gar nicht braucht, deaktiviert sie: add_filter( 'wp_is_application_passwords_available', '__return_false' );
Weiterführende Artikel
- Brute-Force- und Credential-Stuffing-Schutz für wp-login.php und XML-RPC
- Benutzerrollen, Berechtigungen und das Least-Privilege-Prinzip
- REST-API und XML-RPC absichern oder einschränken