Sicherheitsmythos: Anmeldenamen in WordPress verstecken

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.

25 Antworten auf Sicherheitsmythos: Anmeldenamen in WordPress verstecken

  1. Hm, wenn ich das richtig verstehe, dann lässt sich das Argument auf WPTavern auf »Nimm halt 2-Faktor-Authentifizierung« zusammen fassen.

    Rein vom mathematischen Gefühl stellt es schon einen Unterschied dar ob ich ein zehnstelliges Passwort erraten muss oder einen fünfstelligen Login und ein zehnstelliges Passwort.

    Selbst handhabe ich es momentan so, dass ich einen Admin-Account habe, mit dem ich keinerlei Posts schreibe und einen zweiten Account, mit dem ich Arbeite, der aber kein Admin ist. Das hält niemanden davon ab, der es gezielt darauf anlegt, richtet sich aber gegen die vielen automatisierten Angriffe.

    • Danke für deinen Kommentar! Genau das schreibe ich ja auch in meinem Fazit – nutze ein Konto mit weniger Rechten für das Schreiben und den Admin nur für Administrator-Tätigkeiten. Und spätestens mit WordPress 4.5 kommt ohnehin ein weiteres „Problem“ auf uns zu. Dann kann man sich mit der E-Mail-Adresse anmelden: https://core.trac.wordpress.org/changeset/36617

  2. Ich benutze keinen „admin“ als Administratorname. Habe schon viele Einbruchversuche beobachtet, die Hacker benutzten immer „admin“, „Administrator“ oder den Domainnamen.
    Den wahren Adminnamen kann man auch noch schützen, indem man unter „Spitzname“ einen anderen Namen einträgt und unter „Öffentlicher Name“ (das steht gleich unter dem Spitznamen …) dann auswählt. Dann taucht beim schreiben von Seiten oder Artikeln der richtige Adminname auch nicht auf.
    Bis jetzt hat es noch keiner geschafft, sich als Admin anzumelden (bei ~150 WP-Seiten).
    Natürlich gehört dazu noch ein Sicherheitsplugin wie z.B. Wordfence, mit dem man die Loginversuche begrenzen und IPs sperren kann. Wenn so ein Hacker nach jeweils 2 Versuchen eine neue IP braucht, geht ihm irgendwann die Lust aus.

    • Den wahren Adminnamen kann man auch noch schützen, indem man unter „Spitzname“ einen anderen Namen einträgt und unter „Öffentlicher Name“ (das steht gleich unter dem Spitznamen …) dann auswählt. Dann taucht beim schreiben von Seiten oder Artikeln der richtige Adminname auch nicht auf.

      Das ist nicht richtig, da der Anmeldename in der URL steht und eben, wie beschrieben, auch durch andere Methoden herauszubekommen ist. Dein Vorgehen ist somit kein Schutz!

      Wenn so ein Hacker nach jeweils 2 Versuchen eine neue IP braucht, geht ihm irgendwann die Lust aus.

      Das mag für einen einzelnen Menschen zutreffen, aber für skriptbasierte Angriffe ist das eher irrelevant. Und bei einem Angriff über ein Botnetz (mit wechselnder IP) nützt auch dieser Schutz nichts.

      • Das stimmt leider, ich selbst benutze ebenfalls Wordfence für viele verschiedene Webseiten, was auch meistens ganz gut funktioniert. Jedoch treten in letzter Zeit immer häufiger Angriffswellen von *.amazonaws.com auf welche sich einfach nicht blocken lassen, obwohl es scheinbar jedes mal die gleiche IP ist.

      • Danke für die Hinweise, ist doch etwas komplexer als gedacht …

  3. Danke für den lesenswerten Artikel, Torsten!

    Generell schreibe ich meine Artikel stets mit einem Autoren-Account, der kaum bis gar keine Rechte auf der Webseite besitzt. Den Admin-Account nutze ich nur für die Verwaltung. Sicherheitsvorkehrungen treffe ich in der Regel mit dem „AIO WP Security & Firewall Plugin“. Diverse Bots versuchen regelmäßig meine Seiten zu übernehmen, bisher stets ohne Erfolg.

    Was ich hierbei jedoch merkwürdig finde, ist, dass die Bots in seltenen Fällen dennoch meinen Admin-Account kennen (obwohl dieser nie einen Kommentar oder Artikel verfasst hat) und auch die neu adressierte Logon-Seite kennen. Zumindest erscheint es mir so in den Site Lockout Notifications, die ich per Mail erhalte.

    • Was ich hierbei jedoch merkwürdig finde, ist, dass die Bots in seltenen Fällen dennoch meinen Admin-Account kennen

      Danke für den Plugin-Tipp, wobei ich bei diesen All-in-one-Lösungen immer skeptisch bin. – Zu deiner Frage wie die an die Accounts kommen: Ich denke vor allem Weg Nummer 1 aus dem Beitrag.

  4. Was ist denn von fail2ban zu halten? Ist das sinnvoll? Ich denke darüber nach, fail2ban so einzustellen, dass nach drei failed logins innerhalb einer Stunde die IP für einige Tage gesperrt wird. Gegen distributed attacs (also von vielen wechselnden IP-Adressen) hilft das zwar nicht, aber ich sehe in meinen logs, dass die meisten Angriffswellen von einer stabilen IP kommen.

    • fail2ban ist sehr zu empfehlen, aber als Server-Modul natürlich für die Shared-Hoster-Nutzer nicht nutzbar. Und selbst fail2ban weist daraufhin, dass es zwar Last senken kann, aber streng genommen keine ausreichende Sicherheitsfunktion ist. Auch hier wird Zwei-Faktor-Autorisierung empfohlen:

      Fail2Ban is able to reduce the rate of incorrect authentications attempts however it cannot eliminate the risk that weak authentication presents. Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services.

  5. Ich habe meinem Admin-Account nach der fertigen Installation den Status „Member“ gegeben, denn ganz oft nach einer Installation taucht der Account-Name ja doch irgendwo auf. Hab vorher einen neuen Account erstellt, welchen ich ,naklar, einen andern Namen gegeben habe. Wenn jetzt wieder versucht wird, mit dem richtigen Admin-Account auf die Seite zuzugreifen, dann wechsele ich den Namen wieder und mache den alten Account zum „Member“.
    Nach meinem ersten Wechsel waren aber keine Versuche mehr im Log, mit dem Admin-Account Zugriff zu erhalten…
    Ist vielleicht aufwendig, wenn man das auf mehreren Installationen machen muss, aber ich fühle mich damit recht sicher…
    Selbstverständlich wird unter dem Admin-Account nix geschrieben…

  6. SSL Verschlüsselung, eventuell noch was mit htpasswd vor dem Adminbereich, DISALLOW FILE EDIT und ein massiv sperriges Passwort. Dann kann es mir wurscht sein, dass ein „Angreifer“ (meistens ja sowieso nur Bots) den Admin-Benutzernamen kennt. Zumal auf das Login nur etwa 10-20 % der Angriffe laufen.

  7. Sorry, wenn ich an einer Stelle wiedersprechen muss, aber die Sache mit der Autoren-URL stimmt nicht. Es ist vielmehr so, wie von Udo Graesser beschrieben. Auch auf meiner Seite taucht in der URL definitiv der Spitzname auf und nicht der Benutzername. Anmeldeversuche mit real existierenden Nutzernamen hatte ich auf meiner Seite noch gar nicht und die, die versucht haben sich einzuloggen, habe ich bei iThemesSecurity auf die Blacklist gesetzt und seitdem weitestgehend Ruhe.

    Was mich nur wundert: Irgendwoher schaffen es die Bots die geänderte URL des Admin-Logins auszulesen, obwohl ich dazu keinen Link auf meiner Seite habe, weil ich keine Registrierung und Anmeldung für Nutzer verwende, die ich nicht selbst anlege.

    • Das ist nicht korrekt. Wenn Du iThemes Security benutzt, dann sorgt womöglich dieses Plugin dafür. Standardmäßig nutzt WP den user_nicename, welches eine für die URL geeignete Version vom Benutzernamen ist (also z.B. „-“ statt einem Leerzeichen).

  8. Ich betreibe etliche WordPress-Websites und logge dort die Bot-Angriffe mit. Bei sehr vielen Attacken wird versucht das Passwort für den Benutzer „admin“ zu erhalten. Deine Aussage ist zwar korrekt, dass Benutzernamen kein großes Geheimnis darstellen, dennoch bedeutet die Verwendung eines anderen Benutzernamens eine kleinere Angriffsfläche. Also Sinnhaftigkeit: gegeben. Komplexität: gering.

    • Ich bestreite gar nicht die Wirksamkeit generell. Insbesondere bei automatisierten Angriffen auf Standard-Anmeldenamen ist das Nicht-Verwenden von „admin“ ein guter Schritt. Aber ein Laie denkt womöglich, dass dies ein fundiertes Sicherheitskonzept ist. Und dem ist nun mal nicht so. Warum erklärt der Artikel.

  9. Die Erfahrung habe ich auch gemacht. Wenn man »admin«, »adm1n« und »administrator« als Loginnamen blockiert, bevor sie irgendwo gelogged werden, reduziert das bei mir die Angriffe die noch durchkommen um >90%. Ich habe mir irgendwann mal ein Plugin genau dafür geschrieben: https://github.com/dnaber-de/WP-Send-Admin-Home

  10. Hi Torsten,

    endlich bringt es mal jemand auf den Punkt;)
    Das Thema muss man immer mal dem einen oder anderen Kunden erklären. Dazu werde ich den Artikel hier verwenden:)
    Seit ich den Login per htaccess schütze, habe ich eigentlich keine Angriffe mehr zu verzeichnen.

    Gruss Harry

    P.S. Wird es noch ein Update von „Child-Theme-Check“ auf die WP 4.4er Version geben?

  11. Wie wäre es denn, wenn man einfach ausschließlich den Login über ein soziales Netzwerk (Social Login) ermöglicht?

    • Interessante Variante, aber sicher ein zu gewagter Weg für den Core. Aber per Plugin sicher möglich. Das System birgt dann natürlich auch Risiken durch diese Abhängigkeit. Was ist wenn der Dienst down ist? Oder der Dienst gehackt wird? Ist die Implementierung der Autorisierung sicher? Etc.

  12. Reicht es nicht theoretisch den Adminbereich mit einem Captcha zu versehen?
    Habe bislang immer gehört dass die Bots damit nicht klarkommen würden.

  13. >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

    Reicht es da nicht den Spitznamen im Benutzerprofil zu ändern? Bin mir aber grad auch nicht ganz sicher.

    • Nein, das reicht nicht. Der Spitzname wäre ja ggf. nur der „Display Name“. Entscheidend ist aber user_login bzw. user_nicename, wobei user_nicename die sanitized version von user_login ist. Und user_nicename wird für die URLs beim Author Permalink benutzt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *