Absicherung von WordPress-Logins: WP Admin Captcha

Fragen und Antworten

Greift der Aussperrschutz auch bei einem ungültigen Secret Key oder wenn die Prüfanfrage Google nicht erreicht?

Er greift nur, wenn keine Schlüssel hinterlegt sind. Sind Schlüssel vorhanden, wird die Aufgabe erzwungen, und eine Aufgabe, die sich nicht bestätigen lässt, gilt als nicht gelöst. Für eine Sicherheitsprüfung ist das richtig, während eines Ausfalls aber unbequem.

Ein falscher Secret Key und ein nicht erreichbarer Prüfendpunkt sehen von der Anmeldeseite aus deshalb gleich aus: Das Formular weist den Versuch ab. Dann braucht es einen zweiten Zugang, der nicht vom Plugin abhängt: über WP-CLI oder durch Umbenennen des Plugin-Verzeichnisses per SSH. Wer ein Captcha auf der Anmeldeseite einsetzt, sollte diesen Weg einmal ausprobiert haben, bevor er gebraucht wird.

Dazu gehört ein Detail zum Kontingent. Bis 10.000 Bewertungen im Monat ist die Nutzung kostenlos, und jede Prüfanfrage zählt mit. Eine Website unter anhaltendem Druck durch Bots kann diese Zahl erreichen, ohne dass eine einzige Anmeldung gelingt. Was jenseits der Grenze geschieht, hängt von der Abrechnung des Google-Cloud-Projekts ab; bestätigt die Prüfung ab dann nichts mehr, kommt der Fehler durch dieselbe Tür wie der Ausfall oben.

Deckt WP Admin Captcha auch Anmeldeversuche über xmlrpc.php ab?

Indirekt ja, wenn auch nicht so wie auf der Anmeldeseite. Ein Kontrollkästchen setzt eine Oberfläche voraus, und die Schnittstelle hat keine, weil sie Anmeldedaten in einem Aufruf entgegennimmt und maschinell antwortet. Die Prüfung des Plugins hängt aber nicht am Formular, sondern am Filter wp_authenticate_user, den WordPress bei jeder Anmeldung mit Benutzernamen und Kontopasswort durchläuft, auch bei einem Aufruf über xmlrpc.php. Einem solchen Aufruf fehlt das Captcha-Token, das nur das Anmeldeformular mitschickt, und die Anmeldung scheitert, bevor das Passwort überhaupt geprüft wird.

Daraus folgt zweierlei. Passwortversuche über die Schnittstelle laufen ins Leere, solange der Secret Key hinterlegt ist; ohne ihn greift der Aussperrschutz, und die Wirkung entfällt auch hier. Und Programme, die sich über XML-RPC mit dem Kontopasswort anmelden, scheitern ebenso; Anwendungspasswörter prüft WordPress auf einem eigenen Weg, an dem das Plugin nicht ansetzt.

Die Last bleibt trotzdem: Jeder Aufruf erreicht PHP, und eine einzelne Anfrage konnte historisch mehrere Anmeldeversuche bündeln, was Rate-Limits auf Anfrageebene unterläuft. Zwei Maßnahmen greifen dort, wo das Plugin nicht hinreicht. Wo nichts die Schnittstelle braucht – keine App, kein externer Editor, kein Dienst, der Beiträge einliefert –, ist sie abzuschalten; das ist die wirksamste und billigste Antwort. Wo sie gebraucht wird, gehört die Begrenzung eine Ebene tiefer, in den Webserver: eine Sperre nach wenigen Fehlversuchen je Adresse, unabhängig davon, welche Datei angesprochen wurde.

Kann eine Content Security Policy (CSP) der Grund sein, dass das reCAPTCHA-Feld trotz eingetragener Schlüssel fehlt?

Ja, eine CSP ist eine häufige Ursache für dieses Bild. Das Widget lädt Skripte von www.google.com/recaptcha/ und www.gstatic.com/recaptcha/ und bettet das Feld selbst in einen Frame von www.google.com/recaptcha/ ein. Eine Richtlinie, die diese Quellen nicht zulässt, blockiert sie, ohne auf der Seite eine sichtbare Spur zu hinterlassen.

Die Folge wiegt schwerer als das fehlende Feld. Der Aussperrschutz greift nur, wenn keine Schlüssel hinterlegt sind. Da die Schlüssel eingetragen sind, verlangt das Plugin eine Aufgabe, die niemand sieht, und das Formular weist dann jede Anmeldung ab, auch die des Administrators.

Klarheit bringt die Browserkonsole auf der Anmeldeseite: Dort stehen die blockierten Ressourcen samt dem Namen der Direktive. In script-src gehören beide Skriptquellen, in frame-src die Quelle des Frames. Außerdem lohnt es sich, schon vorher einen Zugang zu kennen, der nicht vom Plugin abhängt: Das Umbenennen seines Verzeichnisses per SSH stellt die Anmeldung binnen Sekunden wieder her.