Login-Härten, Benutzername, URL-Slug und Admin-Mail unsichtbar machen

In der letzten Lektion haben wir die Pflicht-Schicht gebaut: einzigartiges Passwort, sauber getrennte Rollen, Application Passwords aufgeräumt. Das schützt dich gut, solange ein Bot nicht weiß, wie dein Admin-Login heißt. Und genau hier liegt die Stelle, an der die meisten Foodblogs auch nach all den Standardtipps noch leaken: WordPress verrät den Login-Namen an mehreren Stellen freiwillig, ohne dass du das je bewusst eingestellt hast.

Wir nennen das in der Agentur "die zweite Tür". Du kannst dein Passwort so stark machen, wie du willst, solange ein Bot deinen Benutzernamen kennt, muss er nur noch eine von zwei Informationen raten. Und die meisten Brute-Force-Angriffe, die wir in den Logs sehen, scheitern nicht, weil das Passwort zu stark war, sondern weil der Bot nach 200 Versuchen mit dem falschen Login-Namen aufgegeben hat. Die Login-Härtung in dieser Lektion sorgt dafür, dass er beim Login-Namen erst gar nicht durchkommt.

Schicht 1: Login-Name nicht "admin", nicht dein Vorname, nicht deine Domain

Bots arbeiten Wordlists ab, und ganz oben auf jeder dieser Listen stehen die Klassiker: admin, administrator, editor, support, info, kontakt, redaktion, dazu der Domain-Name selbst (also foodblogliebe, wenn der Blog foodblogliebe.de heißt) und gängige Vornamen. Wenn dein Login einer dieser Standard-Treffer ist, hat der Bot die Hälfte der Arbeit geschenkt bekommen.

Was du brauchst, ist ein Login-Name, der nicht raten lässt, und der vor allem nichts mit deiner öffentlich sichtbaren Identität zu tun hat. Nicht dein Vorname, nicht der Blogname, nicht die Mailadresse, nicht der Hund. Etwas Generisches und Unauffälliges, das du dir notierst und das nur du kennst.

Der bestehende Account lässt sich in WordPress nicht direkt umbenennen, der Login-Name ist nach dem Anlegen festgeschrieben. Aber zwei einfache Wege gibt es: Entweder du legst einen frischen Admin-Account mit unauffälligem Login an und stufst den alten auf Redakteur runter (Beiträge bleiben, wo sie sind), oder du legst einen neuen Admin an, überträgst die Beiträge per Massen-Aktion in der Beitragsübersicht und löschst den alten User. Welcher Weg sinnvoller ist, hängt davon ab, wie an dir der alte Login-Name liegt, der praktische Klick-Pfad steht im flankierenden Beitrag zu den 12 Sicherheitsmaßnahmen.

Schicht 2: Den URL-Slug vom Login-Namen entkoppeln

Hier wird es spannend, und hier hört bei den meisten Sicherheitstutorials das Wissen auf. Selbst wenn dein Login-Name perfekt unauffällig ist, leakt WordPress ihn an zwei Stellen wieder nach außen, und kaum jemand weiß, dass es diese Stellen gibt.

Stelle eins, die Autoren-URL. Jeder User in WordPress hat eine Autorenseite mit einer URL wie /author/<slug>/. Dieser Slug heißt intern user_nicename und ist nach der Account-Erstellung standardmäßig identisch mit dem Login-Namen. Heißt: Selbst wenn dein Login kati2024 ist, ist deine Autoren-URL /author/kati2024/. Damit hat ein Bot, der deinen Blog 30 Sekunden anschaut, schon den Login-Namen, er muss nur einmal https://deinblog.de/?author=1 aufrufen, WordPress leitet ihn auf /author/<slug>/ weiter, und das Auslesen des Slugs aus der Browser-Adressleiste oder aus dem HTTP-Redirect-Header ist für jeden automatisierten Scanner trivial.

Stelle zwei, die REST API. Aus Lektion 2 kennst du sie schon, /wp-json/wp/v2/users gibt für nicht eingeloggte Anfragen eine JSON-Liste aller User zurück, die mindestens einen veröffentlichten Inhalt haben. Pro User stehen dort drei Felder, die uns interessieren: name (der Anzeigename, weitgehend unkritisch), link (führt auf /author/<slug>/) und slug (genau der user_nicename). Dieser Endpoint ist nicht abschaltbar im klassischen Sinne und sollte es auch nicht sein, er wird vom Block-Editor und vielen modernen Plugins gebraucht. Wir härten stattdessen den Inhalt: Wenn der slug nicht mehr identisch mit dem Login-Namen ist, kann die API liefern, was sie will, sie verrät dann nur noch, dass es einen Account gibt, aber nicht, womit man sich einloggt.

Was du tun musst, ist erstaunlich einfach: In jedem WordPress-User-Profil gibt es ein Feld, das je nach Sprache "URL-Slug", "Spitzname" oder direkt "Anwendername in URLs" heißt. Setz dort etwas Generisches ein wie redaktion, kueche, team oder blog, irgendwas, das nichts mit deinem Login zu tun hat. Den Anzeigenamen kannst du gleichzeitig auf deinen echten Vornamen oder Blognamen setzen, das ist Geschmackssache und macht für die Sicherheit keinen Unterschied. Speichern, fertig.

So testest du, ob die Entkopplung gegriffen hat: Öffne im Browser https://deinblog.de/?author=1. Wenn WordPress dich auf /author/redaktion/ (oder welchen Slug du gewählt hast) weiterleitet, ist die Schicht aktiv. Öffne danach https://deinblog.de/wp-json/wp/v2/users und schau in das Feld slug, es sollte deinen generischen Wert zeigen, nicht deinen Login. Falls du mehrere User hast, wiederhol das mit ?author=2, ?author=3 und so weiter, bis du alle durchhast.

Was wir oft sehen: Bloggerinnen, die ihren Login-Namen sauber auf etwas Unauffälliges geändert haben, aber die Slug-Entkopplung übersehen haben, und damit den Login weiter über die REST API verraten, obwohl sie sich wegen der Login-Umstellung schon halbwegs sicher fühlen. Punkt 2 ohne Punkt 3 ist halbe Arbeit.

Schicht 3: Der Admin-User postet keine Inhalte

Es gibt eine Eigenheit der REST API, die du dir zunutze machen kannst. Seit WordPress 4.7.1 zeigt der Endpoint /wp-json/wp/v2/users für nicht eingeloggte Anfragen nur User an, die mindestens einen veröffentlichten Beitrag haben. Heißt im Klartext: Wenn dein Admin-Account selbst nichts postet, taucht er in der öffentlichen API-Liste gar nicht erst auf, egal, wie sein Login oder Slug heißen.

Das saubere Pattern ist die zweigeteilte Account-Struktur aus Lektion 3 in Reinkultur: Der Admin-User macht ausschließlich Admin-Sachen, Plugin-Updates, Theme-Pflege, Einstellungen. Der Redakteur-Account schreibt und veröffentlicht. Der Admin postet nichts, ist damit unsichtbar in der API.

Es gibt aber eine Falle, die fast jede übersieht und die wir hier ehrlich nennen wollen: "Posten" meint in WordPress nicht nur Blog-Beiträge. Bei modernen Themes und im Block-Editor legst du auch Header, Footer, Popups, Banner oder Layout-Bausteine als kleine eigene Inhaltstypen an, und sobald der Admin-User einmal so ein Element erstellt hat, ist er wieder in der API-Liste sichtbar. In der Praxis ist das schwer durchzuhalten: Header und Footer baust du typischerweise einmal, aber wenn du später ein Popup nachschiebst, einen Hinweisbalken einrichtest oder ein neues Theme-Modul anlegst, passiert der Wechsel in den falschen User schnell.

Deshalb ist diese Schicht ehrlicherweise eine zusätzliche Härtung obendrauf, kein Muss. Wer Schicht 1 und 2 sauber gemacht hat, unauffälliger Login-Name plus entkoppelter Slug, ist auch dann gut abgedeckt, wenn der Admin-User über die REST API doch noch sichtbar wird, weil dann nur der Slug redaktion (oder dein Wert) sichtbar ist und nicht mehr der Login. Schicht 3 ist die zusätzliche Tarnung für die, die es konsequent durchziehen wollen.

Schicht 4: Admin-Mail vom Impressum trennen

Im deutschen Markt brauchst du im Impressum eine erreichbare Mailadresse, Pflicht. Bei den meisten Foodbloggerinnen ist genau diese Mailadresse auch die WordPress-Admin-E-Mail. Damit hast du eine Lücke, die du nicht siehst.

WordPress erlaubt das Zurücksetzen des Passworts per Login-Name oder per E-Mail. Heißt: Selbst wenn dein Login-Name perfekt versteckt ist und der Slug entkoppelt, kann jeder, der dein Impressum liest, den Reset-Flow auf deine Mailadresse anstoßen. Das eigentliche Passwort kommt damit zwar nicht raus, der Reset-Link wird ja an deine Mailadresse geschickt, nicht an den Angreifer -, aber zwei Dinge passieren trotzdem: Phishing wird gezielter (der Angreifer weiß, an welche Adresse echte Reset-Mails gehen, und kann perfekt gefälschte schicken), und falls dein Mailaccount selbst irgendwann kompromittiert wird, ist der WordPress-Login mit dabei.

Die Lösung ist banal: zwei verschiedene Mailadressen. Eine öffentliche, die im Impressum steht, im Kontaktformular landet und im Newsletter-Footer auftaucht, hallo@deinblog.de zum Beispiel. Und eine separate, die ausschließlich die WordPress-Admin-Mail ist und nirgends im Internet sichtbar wird. Beide Postfächer können bei demselben Hoster liegen, das kostet nichts. Entscheidend ist, dass sie öffentlich nichts miteinander zu tun haben.

Die Faustregel

Über die vier Schichten zusammen gilt eine einfache Faustregel, mit der du dich selbst prüfen kannst:

Wer 30 Sekunden auf dein Impressum, deinen Quelltext und /wp-json/wp/v2/users schaut, soll weder deinen Login-Namen noch die E-Mail-Adresse rausfinden, mit der er einen Passwort-Reset starten könnte.

Wenn du diese drei Tests selbst durchspielst, Impressum-Mail offline notieren, Quelltext der Startseite nach author und Mailadressen durchsuchen, REST-API-Endpoint öffnen, und am Ende keine der beiden Informationen vor dir liegt, hat die Login-Härtung gegriffen.

Unser Tipp: Mach den Test heute Abend einmal mit dem eigenen Blog, bevor du irgendwas anpasst, du wirst überrascht sein, was sichtbar ist, ohne dass du es je bewusst veröffentlicht hättest. Die konkreten Klick-Wege für die einzelnen Anpassungen, neuen Admin-User anlegen, alten degradieren, Slug ändern, zweite Mailadresse einrichten, findest du im Beitrag 12 Sicherheitsmaßnahmen, die jeder Foodblogger selbst umsetzen kann, der dieselben vier Punkte mit konkreten Test-URLs und Aufwand-Schätzungen pro Schritt durchgeht.

In der nächsten Lektion drehen wir uns weg von Login und User-Konten und schauen auf die andere große Einbruchsstelle, die wir in der Agentur regelmäßig sehen: Plugins. Welche brauchst du wirklich, woran erkennst du, ob ein Plugin gepflegt wird, und warum "deaktiviert" nicht "weg" heißt.