Seit einiger Zeit werden WordPress-Seiten zum Teil sehr massiv mit Brute-Force Methoden angegriffen, um das Passwort „zu erraten“ für den Admin oder andere User.
Meistens laufen die Angriffe auf „admin“, weil das der erfolgversprechendste User in WordPress Installationen ist, denn erstens war „admin“ früher fest als Administrator-Login vorgeschrieben und zweitens handelt es sich dabei um einen User mit Administrator-Rechten (kann auch PHP-Dateien intern editieren, für Einbrecher also sehr interessant und bösen Code einzubauen) und drittens lassen auch viele den „admin“ als User stehen, obwohl WordPress seit einiger Zeit den Admin-Login bei der Installation frei ändern lässt.
Später kann man den Usernamen (Login-Name) nicht mehr ändern.

Das Problem mit dem Standard-Admin:

Es gibt immer wieder zu lesen, dass man doch bitte aus Sicherheitsgründen nicht mehr „admin“ oder „Admin“ also ersten Usernamen nehmen solle, sondern etwas anderes.
Für andere CMS mag das ja einen Sicherheitsgewinn ausmachen, aber nicht für WordPress, denn die Entwickler haben sich gedacht, man könne sich doch den Usernamen über das Web anzeigen lassen mit diesem Link: http://www.123-blog.de/?author=1

/?author=1 zeigt den URL-tauglichen Usernamen des Nutzers mit der ID=1 an, also immer der User, der bei der Installation als erstes eingetragen wird, nämlich der Administrator mit allen Rechten.
Man kann das Spielchen so fort führen indem man einfach alle Nummer durchprobiert und schaut, ob Antworten kommen, und tatsächlich fand ich in den Logfiles die Anfragen mit allen Nummern bis 99 durch die Angriffs-Programme (die Angreifer sind meistens automatische Programme).

Die Antwort vom WordPress-Programm sieht dann z.B. so aus: http://www.123-blog.de/author/admin
„Juchhu„, sagt sich das Angriffsprogramm, „ich hab den Usernamen!“ und tatsächlich stimmt es in den meisten Fällen auch, weil der Standard-Username eben „admin“ lautet.

Es mag durchaus Sinn gehabt haben, warum man so einfach den Login-Namen herausfinden kann, denn als WordPress noch jung war, war von solchen Angriffen wie sie heute statt finden, kaum die Rede und WordPress wollte vielleicht eine einfach Möglichkeit bieten, wie man automatisch den Autor herausfinden und auf alle Beiträge dieses Autors verlinken kann.
Inzwischen aber haben sich die Möglichkeiten für die Angreifer erheblich verbessert, dank der schnellen Datenleitungen und Server können die Angreifer tatsächlich einfach alle möglichen und unmöglichen Passwörter durchtesten beim Loginversuch mit dem User „admin“.
Steter Tropfen höhlt den Stein und irgendwann passt vielleicht zufällig ein Passwort und schon ist eine weitere WordPress-Seite gehackt, ganz automatisch und ohne Mühe für den Angreifer.

Der oft gelesene Ratschlag, den „admin“ zu löschen und einen neuen User einzutragen oder bei der Installation einen anderen Namen zu wählen, nützt meistens nichts. Warum?
Weil WordPress automatisch den gewählten Usernamen nimmt und daraus einen URL-tauglichen Namen erzeugt und in die Datenbank speichert. Somit kann das Angriffs-Programm ganz einfach mit dem Author-Link (der mit dem Fragezeichen) den Usernamen wieder heraus finden. Damit ist nicht wirklich viel gewonnen und man wägt sich in trügerischer Sicherheit.

Aber es gibt Unterschiede, die man nutzen kann:

Da WordPress einen URL-tauglichen Namen generiert, dürfen darin keine Sonderzeichen und keine Umlaute vorkommen. So könnte man doch auf den Gedanken kommen, den Usernamen „ädmin“ statt „admin“ zu wählen, mit einem ä am Anfang. Aber WordPress lässt für die Wahl des Usernamen keine solche Sonderzeichen zu, wir ahnen warum (soll ja URL-tauglich werden und hat vielleicht noch historische Gründe und wegen lokaler Unterschiede in der Tastatur usw.) Es wäre zu schön gewesen, hätte WordPress aus dem „ädmin“ einfach ein „admin“ gemacht. Auch z.B. ein # im Namen wird nicht akzeptiert.

Es gibt aber noch mehr, was man ausnützen kann, denn Großbuchstaben werden klein gemacht und Leerzeichen werden mit einem Bindestrich versehen. An dieser Stelle sei vermerkt, dass ein Leerzeichen im Usernamen alleine keine besondere Sicherheit darstellt, weil es für Programmierer leicht ist, beim Antreffen eines Bindestriches auf ein Leerzeichen im Login-Namen zu schließen und das entsprechend zu programmieren.
Aber eine Kombination aus beidem könnte doch deutlich mehr Sicherheit bringen:

• KlausMaus wird zu klausmaus
• Klaus Maus wird zu klaus-maus
• klauS MauS wird auch zu klaus-maus

Wir sehen hier, dass man mit der Kombination von Groß- und Kleinschreibung an verschiedenen Stellen (und vielleicht noch mit Leerzeichen) durchaus einiges zu Rätseln für das Angriffs-Programm aufgibt. Alleine das zu knacken könnte schon dauern, je nachdem wie verschachtelt man das schreibt: KlaUsmAuS-zUhauS und das Angreifer-Programm dürfte alle möglichen Kombinationen durchprobieren müssen, bis der richtige Login-Name mal getroffen wäre.

Und nun stelle man sich das noch in Kombination mit einem langen und sicheren Passwort vor, mit Sonderzeichen, Zahlen, Groß-Kleinschrift. Das dürfte eigentlich kaum noch zu knacken sein, es sind vermutlich zu viele Kombinationen.
Das muss man dann aber für alle User so durchführen, denn es werden auch die anderen User gefunden und darauf angegriffen.

Und dann bitte nicht für den „Angezeigten Namen“ (display name) den original Login-Namen stehen lassen!! Sonst war alles umsonst.

Es geht aber noch besser:

(auf eigenes Risiko* für Datenbankversierte User)

Wer meinen Link oben ausprobiert hat, wird sehen, dass tatsächlich „admin“ angezeigt wird.
Bin ich etwa so leichtsinnig, und habe als Usernamen nur admin oder Admin gewählt?
Nein, bin ich nicht, es ist ein Honeypot (Honigtopf), extra für die lieben, dummen Angriffsprogramme so stehen gelassen.
Einem so leckeren Honigtopf können diese Programme gar nicht widerstehen, sind sie doch vornehmlich auf „admin“ getrimmt.
Was habe ich gemacht?

In der Datenbank gibt es in der Tabelle wp_users (man sollte hier durchaus bei der Installation auch einen anderen Präfix wählen statt „wp“) zweierlei Spalten für Login-Name und eben diese URL-taugliche Version.
In der Spalte user_login steht der tatsächliche Login-Name (Username) und in der Spalte user_nicename steht eben dieser URL-taugliche Name. Den trägt WordPress automatisch ein und den kann man nicht vom Backend aus ändern.
An dieser Stelle noch die Anmerkung: user_nicename ist nicht der Nickname, auch wenn es sich ähnlich liest, es ist eher ein Alias-Name für technische Dinge wie eben die URL.
Da WordPress seit einiger Zeit es ermöglicht, einen Nicknamen einzutragen, könnte man das miteinander verwechseln.
Aber zum einen taucht der Nickname, den man selbst wählen kann, gar nicht in dieser Tabelle auf, sondern in der Tabelle wp_usermeta.  Und zum anderen kann man diesen Namen mit Sonderzeichen und Umlauten verwenden.
Merke: user_nicename ist nicht Nickname.

Nun, da WordPress mir nicht ermöglicht, den user_nicename zu ändern, mache ich es einfach über die Datenbank, aber anders herum.

1. Ich installiere WordPress mit Usernamen „admin“.
2. Nach der Installation gehe ich in die Datenbank, und ändere direkt in der Tabelle den Usernamen in user_login (nicht den user_nicename) von „admin“ auf irgendwas anderes (was ich garantiert nicht verrate), ohne Sonderzeichen oder Umlaute.
3. fertig

Das war’s, mehr ist nicht.
Kann man auch jederzeit nachträglich machen.
Für die dummen Angriffsprogramme bleibt der angezeigt Autor weiterhin „admin“ (was ungemein verlockend ist).
Wordpress scheint trotzdem ganz gut zu funktionieren, obwohl diese beiden Namen ganz unterschiedlich sind.
Und ich logge mich dann unter dem neuen Namen ein statt mit admin, und es funktioniert prächtig,
* (hoffentlich ändert das WordPress nicht irgendwann mal, aus „Sicherheitsgründen“ womöglich, denn dann könnte es schwer werden, sich noch einzuloggen).

Tatsächlich laufen bei mir immer noch täglich sehr viele Angriffe auf den Namen „admin“, aber die Chancen sind gleich Null, weil es einen „admin“ als User eben darum nicht gibt.
So oft ich auch die Login-Fehlversuchs-Statistik ansehe, es lautet fast immer auf „admin“. Tja, mit Honig fängt man nicht nur Fliegen, sondern auch Angriffs-Programme.
Um die Angriffe nicht ins Uferlose treiben zu lassen, habe ich zusätzlich noch ein Plugin installiert, das fehlerhafte Loginversuche begrenzt und eine Zeit lang sperrt. Trotzdem kommen noch täglich 20 bis 100 Sperrungsmeldungen (die Loginversuche sind also viel mehr).

Hatte ich schon erwähnt, dass das Passwort natürlich trotzdem sicher sein sollte?

Um die lästigen Loginversuche abzuwenden, könnte ich auch einfach noch das Admin-Verzeichnis mit Usernamen und Passwort sichern, mittels .htpasswd zum Beispiel. Dann müsste ich mich zwar immer zweimal einloggen um ins Backend zu kommen aber dafür kämen die Angreifer erst gar nicht mehr zum Login-Bereich. Das sei jedem geraten, der seine Seite sicherer haben will.
Ich tue es nur nicht, weil ich auf dem Laufenden sein will, was sich da so tut.