Passwort-Richtlinien und Anwendungspasswörter in WordPress verwalten

WordPress kennt zwei Arten von Passwörtern: das normale Anmeldepasswort für das Backend und Anwendungspasswörter, mit denen externe Programme über die REST-API zugreifen, etwa eine Warenwirtschaft, ein Newsletter-Dienst oder ein Automatisierungswerkzeug. Beide brauchen Regeln. WordPress selbst setzt keine Mindestlänge für Anmeldepasswörter durch, und Anwendungspasswörter geraten nach der Einrichtung schnell in Vergessenheit, obwohl sie dauerhaft Zugriff gewähren. Diese Anleitung zeigt, wie Sie beides mit Bordmitteln, WP-CLI und einem kurzen Must-Use-Plugin im Griff behalten. Alle Schritte wurden mit WordPress 7.1.2 getestet.

Voraussetzungen

• WordPress 7.1 (getestet mit 7.1.2) auf PHP 8.x
• Website mit gültigem HTTPS-Zertifikat, sonst sind Anwendungspasswörter nicht verfügbar
• Benutzerkonto mit der Rolle Administrator
• Zugriff auf das Dateisystem per SFTP oder SSH, um ein Must-Use-Plugin abzulegen
• Optional: WP-CLI (getestet mit 2.12.0) für Übersicht und Widerruf auf der Kommandozeile
• Ein aktuelles Backup, bevor Sie Code in wp-content/mu-plugins ablegen

Schritt 1: Ausgangslage verstehen

Seit WordPress 6.8 werden Anmeldepasswörter mit bcrypt gespeichert. Im Labor beginnt der gespeicherte Hash in der Tabelle wp_users mit dem Präfix $wp$, das WordPress für seine bcrypt-Variante verwendet. Das schützt Passwörter, falls ein Angreifer die Datenbank kopiert, ersetzt aber keine starken Passwörter.

Beim Setzen eines Passworts unter Benutzer → Profil zeigt WordPress eine Stärkeanzeige. Wählt jemand ein schwaches Passwort, muss er das Kontrollkästchen „Verwendung des schwachen Passworts bestätigen“ setzen, danach akzeptiert WordPress es trotzdem. Auf der Kommandozeile gibt es keine Prüfung: wp user update admin --user_pass=kurz lief im Test mit „Success: Updated user 1.“ durch.

Anwendungspasswörter sind 24 Zeichen lange, von WordPress erzeugte Zufallswerte. Sie gelten nur für API-Zugriffe wie die REST-API, nicht für die Anmeldung unter wp-login.php. Im Test lieferte ein Anmeldeversuch mit einem Anwendungspasswort im Login-Formular keine Weiterleitung ins Backend, sondern wieder das Formular.

Verifizieren: Sie wissen, welche Benutzer Administrator- oder Redakteursrechte haben (wp user list --fields=user_login,roles) und welche externen Programme auf die Website zugreifen.

Schritt 2: Passwort-Richtlinie festlegen

Eine Richtlinie für kleine Unternehmen muss nicht kompliziert sein. Bewährt haben sich wenige, klare Regeln:

• Mindestlänge statt Zeichenvorschriften. Eine lange Passphrase ist leichter zu merken und schwerer zu erraten als ein kurzes Passwort mit Sonderzeichen.
• Jedes Konto hat ein eigenes Passwort, das nirgends sonst verwendet wird. Ein Passwortmanager im Team macht das praktikabel.
• Kein regelmäßiger Zwangswechsel ohne Anlass, aber sofortiger Wechsel bei Verdacht oder wenn eine Person das Unternehmen verlässt.
• Zwei-Faktor-Anmeldung für alle Konten mit Administrator- oder Redakteursrechten.

Schreiben Sie die Regeln in wenigen Sätzen auf und legen Sie fest, wer neue Konten anlegt und alte entfernt.

Verifizieren: Die Richtlinie ist schriftlich festgehalten, allen Beteiligten bekannt, und eine Person ist für Konten zuständig.

Schritt 3: Mindestlänge technisch durchsetzen

WordPress bietet zwei Hooks, über die sich Passwörter beim Setzen prüfen lassen: user_profile_update_errors greift beim Bearbeiten von Profilen und beim Anlegen von Benutzern im Backend, validate_password_reset beim Zurücksetzen über „Passwort vergessen“. Ein Must-Use-Plugin ist dafür der richtige Ort: WordPress lädt Dateien in wp-content/mu-plugins automatisch, und sie lassen sich im Backend nicht versehentlich deaktivieren.

Legen Sie den Ordner an, falls er fehlt, und speichern Sie dort die Datei pw-minimum.php:

<?php
/**
 * Plugin Name: Passwort-Mindestlänge
 * Description: Verlangt beim Setzen eines Passworts im Profil und beim Zurücksetzen mindestens 12 Zeichen.
 */

const SEDV_PW_MIN = 12;

function sedv_pw_zu_kurz( $pass ) {
	return is_string( $pass ) && '' !== $pass && mb_strlen( $pass ) < SEDV_PW_MIN;
}

// Profil, Benutzer bearbeiten, Benutzer anlegen (wp-admin)
add_action( 'user_profile_update_errors', function ( $errors ) {
	if ( isset( $_POST['pass1'] ) && sedv_pw_zu_kurz( wp_unslash( $_POST['pass1'] ) ) ) {
		$errors->add( 'pass', sprintf( 'Das Passwort muss mindestens %d Zeichen lang sein.', SEDV_PW_MIN ) );
	}
} );

// Passwort vergessen: neues Passwort setzen (wp-login.php?action=rp)
add_action( 'validate_password_reset', function ( $errors ) {
	if ( isset( $_POST['pass1'] ) && sedv_pw_zu_kurz( wp_unslash( $_POST['pass1'] ) ) ) {
		$errors->add( 'pass', sprintf( 'Das Passwort muss mindestens %d Zeichen lang sein.', SEDV_PW_MIN ) );
	}
} );

Prüfen Sie die Datei vor dem Hochladen auf Syntaxfehler, denn ein Fehler in einem Must-Use-Plugin legt die ganze Website lahm:

php -l wp-content/mu-plugins/pw-minimum.php

Im Test wurde ein sieben Zeichen langes Passwort im Profil mit „Das Passwort muss mindestens 12 Zeichen lang sein.“ abgelehnt, eine längere Passphrase angenommen. Beim Zurücksetzen erschien dieselbe Meldung. Die Grenze dieses Ansatzes: WP-CLI und Plugins, die Passwörter direkt über wp_set_password() setzen, umgehen die Hooks. Für die Anmeldung von Kunden in Shop-Plugins gelten oft eigene Formulare; prüfen Sie dort die Einstellungen des Plugins.

Verifizieren: wp plugin list --status=must-use führt pw-minimum auf. Unter Benutzer → Profil wird ein kurzes Passwort nach Klick auf „Profil aktualisieren“ mit der Fehlermeldung abgelehnt.

Schritt 4: Anwendungspasswörter anlegen

Anwendungspasswörter sind nur verfügbar, wenn die Website über HTTPS läuft oder die Konstante WP_ENVIRONMENT_TYPE auf local steht. Im Labor ohne HTTPS fehlte der Bereich deshalb zunächst, wp_is_application_passwords_available() lieferte false. Auf einer Produktivseite ist fehlendes HTTPS der häufigste Grund für einen fehlenden Abschnitt.

Im Backend legen Sie ein Anwendungspasswort unter Benutzer → Profil im Abschnitt „Anwendungspasswörter“ an: Name eintragen und „Anwendungspasswort hinzufügen“ klicken. WordPress zeigt das Passwort genau einmal an. Speichern Sie es direkt im Passwortmanager oder in der Zielanwendung.

Auf der Kommandozeile:

wp user application-password create admin "Buchhaltung-Export" --app-id=erp --porcelain

--porcelain gibt nur das Passwort aus, was sich für Skripte eignet. Vergeben Sie für jede Anwendung ein eigenes Passwort mit sprechendem Namen. Nur so können Sie später einen Zugang widerrufen, ohne alle anderen zu unterbrechen. Legen Sie das Passwort bei einem Benutzer an, der nur die nötigen Rechte hat: Ein Anwendungspasswort erbt alle Rechte des Kontos.

Verifizieren: Ein Aufruf mit dem neuen Passwort liefert die Daten des Benutzers statt eines Fehlers:

curl -u 'admin:XXXX XXXX XXXX XXXX XXXX XXXX' https://www.example.com/wp-json/wp/v2/users/me

Ohne Zugangsdaten antwortet WordPress mit Status 401 und dem Fehlercode rest_not_logged_in.

Schritt 5: Anwendungspasswörter überwachen und widerrufen

WordPress protokolliert für jedes Anwendungspasswort den Zeitpunkt und die IP-Adresse der letzten Verwendung. Im Backend sehen Sie das unter Benutzer → Profil in den Spalten „Zuletzt verwendet“ und „Letzte IP“, per WP-CLI für einen Benutzer so:

wp user application-password list admin --fields=name,app_id,created,last_used,last_ip

Im Test stand nach einem REST-Aufruf in last_used ein Unix-Zeitstempel und in last_ip die Adresse des Aufrufers; nie genutzte Einträge bleiben leer. Ein Eintrag, der seit Monaten nicht verwendet wurde, gehört gelöscht. Eine unbekannte IP-Adresse ist ein Grund, das Passwort sofort zu widerrufen.

Einzelne Passwörter widerrufen Sie im Profil mit „Widerrufen“, alle eines Benutzers mit „Alle Anwendungspasswörter widerrufen“. Per WP-CLI:

wp user application-password delete admin UUID
wp user application-password delete admin --all

Im Test meldete der zweite Befehl „Success: Deleted all application passwords.“. Planen Sie die Durchsicht fest ein, zum Beispiel monatlich zusammen mit den Updates. Wer diese wiederkehrenden Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung der Firewall.

Verifizieren: wp user application-password list admin --format=count gibt nur die Zahl der Einträge aus, die tatsächlich gebraucht werden. Nach dem Löschen aller Einträge lautete die Ausgabe im Test 0.

Schritt 6: Anwendungspasswörter auf Rollen beschränken

Standardmäßig darf jeder Benutzer eigene Anwendungspasswörter anlegen. Brauchen nur Administratoren diese Funktion, schränken Sie sie mit einem zweiten Must-Use-Plugin ein, zum Beispiel app-pw-nur-admins.php:

<?php
/* Plugin Name: Anwendungspasswörter nur für Administratoren */
add_filter( 'wp_is_application_passwords_available_for_user', function ( $available, $user ) {
	return $available && user_can( $user, 'manage_options' );
}, 10, 2 );

Im Test lieferte wp_is_application_passwords_available_for_user() danach für den Administrator true, für einen Redakteur false. Wichtig: WP-CLI legte für den Redakteur trotzdem noch ein Passwort an, die Anmeldung damit über die REST-API scheiterte aber mit Status 401. Der Filter blockiert also die Nutzung, räumt aber keine bestehenden Einträge auf. Widerrufen Sie vorhandene Passwörter der betroffenen Rollen deshalb zusätzlich.

Ganz abschalten lässt sich die Funktion über den Filter wp_is_application_passwords_available mit Rückgabewert false. Tun Sie das nur, wenn sicher keine Anwendung sie nutzt; die Liste aus Schritt 5 zeigt das.

Verifizieren: Ein Redakteur sieht unter Benutzer → Profil keinen Abschnitt „Anwendungspasswörter“ mehr, und ein REST-Aufruf mit einem vorhandenen Redakteurs-Passwort liefert 401.

Typische Fehler

Häufige Fragen

Brauche ich zusätzlich ein Sicherheits-Plugin für Passwort-Richtlinien?

Für eine Mindestlänge nicht. Plugins lohnen sich, wenn Sie weitere Funktionen wie Zwei-Faktor-Anmeldung oder Sperren nach Fehlversuchen ohnehin brauchen. Die Zwei-Faktor-Anmeldung beschreibt die Anleitung WordPress-Login mit Zwei-Faktor-Authentifizierung absichern.

Umgehen Anwendungspasswörter die Zwei-Faktor-Anmeldung?

Ja, das ist ihr Zweck: Programme können keinen zweiten Faktor eingeben. Umso wichtiger sind eigene Passwörter je Anwendung, minimale Rechte und regelmäßiger Widerruf. XML-RPC akzeptiert Anwendungspasswörter ebenfalls; brauchen Sie es nicht, schalten Sie es ab, siehe XML-RPC deaktivieren oder einschränken.

Was tun, wenn ein Mitarbeiter das Unternehmen verlässt?

Konto entfernen und die Inhalte einem anderen Benutzer zuweisen, etwa mit wp user delete ID --reassign=ANDERE_ID. Damit verschwinden auch dessen Anwendungspasswörter. Kannte die Person gemeinsam genutzte Zugänge, ändern Sie diese ebenfalls.

Testumfang

Wir haben alles in einer lokalen Testinstanz mit WordPress 7.1.2 nachgestellt. Geprüft haben wir vor allem, ob Passwörter mit bcrypt gehasht werden und ob das Must-Use-Plugin die Mindestlänge im Profil und beim Zurücksetzen durchsetzt.

Außerdem haben wir Anwendungspasswörter ohne HTTPS mit WP_ENVIRONMENT_TYPE=local ausprobiert, vom Anlegen bis zum Widerruf. Die Oberfläche im Browser und die Passwort-Regeln von Shop-Plugins haben wir nicht getestet, probieren Sie Änderungen daher zuerst auf einer Kopie aus.

Fazit

Mit einer schriftlichen Richtlinie, einem kurzen Must-Use-Plugin für die Mindestlänge und einer monatlichen Durchsicht der Anwendungspasswörter schließen Sie zwei häufig übersehene Lücken ohne zusätzliches Plugin. Entscheidend ist die Regelmäßigkeit: Anwendungspasswörter, die niemand mehr braucht, müssen weg. Wenn Sie diese Pflege zusammen mit Updates und Backups abgeben möchten, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Login mit Zwei-Faktor-Authentifizierung absichern
• XML-RPC in WordPress deaktivieren oder einschränken
• Gehackte WordPress-Seite erkennen: Anzeichen prüfen und erste Schritte
• Make WordPress Core: Application Passwords Integration Guide
• WP-CLI-Handbuch: wp user application-password
• Make WordPress Core: WordPress 6.8 will use bcrypt for password hashing