Immer wieder lese ich den folgenden Sicherheits-Hinweis für WordPress: Verstecke den Anmeldenamen! Oder Nutzer beschweren sich über die Nachlässigkeit der Core-Entwickler, dass der Nutzername preisgegeben wird. Dabei ist das kein Sicherheitsproblem. Und warum das Verschleiern viel schwieriger ist, als viele annehmen versuche ich euch hier mal zu zeigen.
WordPress hat lange Zeit als Standard-Anmeldenamen „admin“ benutzt. Auch wenn das schon lange durch eine freie Eingabe ersetzt wurde, wird dieser Anmeldename immer noch gerne benutzt. Die einschlägigen Sicherheitsexperten geben daher gerne den Tipp: Wechselt den Anmeldenamen zu etwas anderem, so muss der Angreifer nicht nur das Passwort herausfinden, sondern zusätzlich auch den Login erraten.
In diesen Artikeln, häufig in leicht konsumierbarer Listenform verfasst, befindet sich meist kein Hinweis auf die Sinnhaftigkeit dieses Tipps oder die Komplexität der Umsetzung. Denn ohne weitere Maßnahmen verpufft die gut gemeinte Idee leider zur Wirkungslosigkeit.
Die WordPress Core-Entwickler haben schon mehrfach im Trac (dem Bugticket-System, welches WordPress nutzt) klargestellt, dass für sie der Anmeldename kein Geheimnis darstellt. Hier ein paar Möglichkeiten, warum das so ist:
Nummer 1: Permalinks
Bei aktivierten Permalinks werden URLs, die eine Autoren-ID enthalten /?author=1 auf den Anmeldenamen umgeschrieben, also zum Beispiel zu /author/username/.
In einem Blog mit mehreren Autoren und Angabe des Autorenlink im Theme, wird dieser Link sogar direkt angezeigt.
Was wäre eine mögliche Lösung? Du könntest in der Datenbank die User-ID auf einen kryptischen, extrem hohen Wert abändern. Aber mit einem Tool wie WPScan kann ich das jederzeit ganz leicht durchtesten. Schon besser ist der Ansatz mit einem Plugin wie Edit Author Slug oder WP Author Slug den für die URL verwendeten nicename zu ändern (alternativ kann das auch per Änderung in der Datenbank gemacht werden).
Ein weiterer Ansatz wäre das Ganze per .htaccess abzufangen und zum Beispiel auf die Startseite umzuleiten:
RewriteRule \?author=\d+ http://example.com [R=301,L]
Aber es gibt ja noch mehr Möglichkeiten den Nutzernamen preiszugeben …
Nummer 2: Kommentar-Klasse
Standardmäßig werden bei den Kommentaren die Kommentar-Klassen per comment_class gesetzt. Hierbei gilt unter anderem folgendes laut dem WordPress-Codex:
if the comment was made by a registered user, then adds class „byuser“ and „comment-author-“ + the user_nicename sanitized (i.e. spaces removed).
Kommentieren wir also in unserem eigenen Blog als registrierter Benutzer, so wird unser Anmeldename als Klasse comment-author-username auslesbar. Das lässt sich aber über einen Filter ausbügeln. Die Ausgabe wird einfach nach comment-author-* durchsucht und dieser Teil dann entfernt.
Nummer 3: Login und Passwort vergessen
Wenn ich den falschen Anmeldenamen in das Anmeldefenster eintrage, dann wird er nach dem Absenden herausgelöscht. Ist der Anmeldename richtig, dann passiert das nicht. Marc Nilius hat dazu eine Lösung als Gist veröffentlicht.
In den „Expertentipps“ geistert dagegen zum Teil immer noch dieses uralte Snippet herum:
/** * remove Error-information */ add_filter( 'login_errors', create_function( '$a', "return null;" ) );
Damit wird einfach gar keine Fehlermeldung ausgeben und das oben erwähnte Verhalten ist auch nicht gelöst.
Auch die „Passwort vergessen“-Funktion reagiert auf einen korrekten Benutzer mit einer Bestätigung des Mailversands und auf einen falschen Benutzernamen mit einer Fehlermeldung.
Da die Core-Entwickler alle Tickets zu diesem Thema auf Wontfix stellen, wird es neben diesen drei Fällen womöglich noch andere geben. Neue Features werden nicht darauf achten, ob der Username ausgegeben wird. Daher konzentrieren wir uns doch auf echte Lösungen.
Das Verwenden eines Kontos mit der Rolle „Redakteur“ zum Schreiben der Artikel ist eine gute, einfache Möglichkeit, die Sicherheit ein wenig zu erhöhen. Die Empfehlung der Core-Entwickler sind vor allem starke Passwörter (per Passwort-Manager) und eine zusätzliche Sicherungsebene. Das kann ein zusätzliches Passwort per htaccess sein oder eine Zwei-Faktor-Autorisierung. Auch eine SSL-Verschlüsselung der Website (https) ist sinnvoll, um eine Übertragung der Passwörter im Klartext zu verhindern.