Passwörter, Benutzerrechte und Zwei-Faktor

Bei Blog-Übernahmen sehen wir Passwörter wie "Foodblog2023", den Blognamen mit einer Zahl dahinter, oder den Hundenamen plus Ausrufezeichen. Das ist ungefähr so sicher wie die Haustür mit einem Post-it abzukleben, und genau das ist die Schicht, an der die Bot-Mechanik aus der letzten Lektion zuerst andockt.

Ein sicheres Passwort hat mindestens 16 Zeichen, mischt Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen. Und vor allem: Es wird nirgendwo sonst verwendet. Das gleiche Passwort für WordPress, Mail-Account und Instagram ist eine offene Einladung, wenn einer dieser Dienste leakt, kursiert die Kombination automatisch in den Wordlists, mit denen Bots am nächsten Morgen genau deinen WordPress-Login bearbeiten. Credential Stuffing aus Lektion 2 ist nicht abstrakt, das ist der häufigste Einbruchsweg, den wir in der Agentur reparieren.

Solche Passwörter muss man sich nicht merken können. Genau dafür gibt es Passwort-Manager, und davon gibt es genügend gute, die nichts kosten oder im niedrigen Euro-Bereich pro Monat liegen. Welcher konkret, ist Geschmackssache, was zählt, ist das Prinzip: Du merkst dir ein einziges sehr starkes Master-Passwort, der Manager generiert für jeden Dienst ein eigenes Zufallspasswort und füllt es beim Login automatisch aus. Das kostet einmal einen halben Abend Einrichtung und spart dir danach den Stress, dir Passwörter merken oder ausdenken zu müssen.

Was wir oft sehen: Bloggerinnen, die fünf, sechs Konten in einer Notiz-App auf dem Handy gespeichert haben, das einzigartige Passwörter sein sollen, sind es aber nicht, weil das Tippen so lästig war, dass am Ende doch wieder Variationen desselben Worts drin stehen. Ein Manager nimmt diesen Reibungspunkt komplett raus.

So weit zur Pflicht-Schicht eins. Mindestens genauso wichtig wie das Passwort selbst sind die Benutzerrechte in WordPress.

WordPress unterscheidet fünf Rollen: Administrator (darf alles, Plugins installieren, Theme wechseln, Benutzer löschen, an die Datenbank ran), Redakteur (darf alle Beiträge schreiben, bearbeiten und veröffentlichen, auch fremde), Autor (darf nur eigene Beiträge schreiben und veröffentlichen), Mitarbeiter (darf eigene Beiträge schreiben, aber nicht veröffentlichen, ein Admin muss freigeben), Abonnent (darf nur sein Profil pflegen). Wer als Foodblogger jeden Tag Rezepte schreibt, braucht keine Administrator-Rechte für diese Arbeit. Trotzdem läuft fast jeder Single-Author-Blog, den wir übernehmen, mit einem einzigen Admin-Account, der dauerhaft eingeloggt ist und gleichzeitig postet, Plugins updatet und das Impressum verwaltet.

Das Problem an dieser Konstruktion ist nicht der Komfort, sondern das Risiko: Wenn ein Angreifer diesen einen Account übernimmt, hat er die volle Kontrolle. Plugin installieren, das Theme austauschen, Datenbank-Hooks setzen, alle anderen User anlegen, alles in einer Hand. Wenn er stattdessen nur einen Redakteur-Account übernimmt, kann er zwar Beiträge umschreiben (was ärgerlich ist), aber er kommt nicht an die Plugins, nicht an das Theme, nicht an die Benutzerverwaltung.

Die saubere Konstruktion ist deshalb: Zwei Accounts, zwei Aufgaben. Du legst einen separaten Administrator-Account an, der ausschließlich für technische Aufgaben gedacht ist, Plugin-Updates, Theme-Pflege, Einstellungen, Benutzerverwaltung. Und einen zweiten Account mit der Rolle Redakteur, mit dem du tatsächlich täglich postest. In den allermeisten Foodblog-Workflows reicht Redakteur völlig aus: alle Beiträge schreiben, alle Beiträge veröffentlichen, Mediathek voll nutzen. Was fehlt, Plugin-Installation und Theme-Wechsel, machst du sowieso nur ein paar Mal im Jahr, da ist der kurze Login-Wechsel zum Admin-Account zumutbar.

Wenn du im Team arbeitest oder Gastbeiträge bekommst, gilt das Gleiche eine Stufe weiter unten: Hauptautoren bekommen Redakteur (können fremde Beiträge bearbeiten), Gastbeiträger bekommen Autor (können nur ihre eigenen anfassen) oder Mitarbeiter (können schreiben, aber nicht veröffentlichen, gut, wenn du jeden Gastbeitrag freigeben willst).

Bleibt die Frage, die in jedem Sicherheitstutorial weit oben steht: Zwei-Faktor-Authentifizierung. 2FA fügt eine zweite Sicherheitsebene hinzu, selbst wer dein Passwort kennt, braucht zusätzlich einen zeitbasierten Code aus einer App wie Google Authenticator oder Authy, oder einen Hardware-Token. Technisch stoppt das den Großteil aller Brute-Force- und Credential-Stuffing-Angriffe an dieser Stelle, und das ist nicht zu unterschätzen.

Hier müssen wir aber ehrlich sein, und das ist der Punkt, an dem wir vom typischen Sicherheitstutorial bewusst abweichen. 2FA ist wirksam, ja, aber Disziplin-Sache. In der Agenturpraxis sehen wir genauso oft Lockout-Fälle wie 2FA-vereitelte Hacks: Backup-Codes verlegt, App auf nur einem Gerät installiert, Smartphone gewechselt ohne Recovery, Cloud-Sync war aus, Google-Konto mit den Authenticator-Codes ist mit gewechselt aber das Passwort ist seit der Datenmigration auch weg. Der typische Anruf in der Agentur lautet dann: "Mein Login funktioniert nicht mehr, ich komme nicht in meinen eigenen Blog rein, was tun?", und der Weg da raus geht je nach Hoster über Datenbank-Eingriff, Mail-Reset oder kompletten Account-Recover. Keine Stunde Spaß für niemanden.

Heißt das, lass 2FA bleiben? Nein, heißt es nicht. Heißt aber: 2FA aktivierst du mit Plan, oder du aktivierst es gar nicht. Plan bedeutet konkret: Backup-Codes ausgedruckt oder in einem zweiten Passwort-Manager-Eintrag, der nicht auf demselben Gerät liegt. Authenticator-App nicht nur auf dem Handy, sondern auch in einer Backup-Lösung (zweites Gerät, ausgedruckte Recovery-Keys, oder eine App, die Cloud-Sync ehrlich anbietet). Und ein realistischer Notfallplan: Wenn das Handy weg ist, was ist mein nächster Schritt, und kannst du den heute Abend in fünf Minuten beantworten, ohne nachzulesen?

Wer Disziplin und Backup-Plan hat: 2FA ja, sehr gerne. Wer das ehrlich für sich nicht sicherstellen kann, ist mit der Pflicht-Schicht aus dieser Lektion (starkes einzigartiges Passwort + separater Admin-User) plus der Login-Härtung aus der nächsten Lektion plus einem Login-Versuche-Limit, das wir in Teil 2 dieser Reihe behandeln, gegen die häufigsten realen Angriffsmuster gut abgedeckt. Das ist kein Freifahrtschein, sondern eine ehrliche Risiko-Abwägung, der zusätzliche Schutz durch 2FA ist real, aber das Lockout-Risiko ist es eben auch, und für eine alleinarbeitende Foodbloggerin ohne IT-Abteilung im Hintergrund kann das Lockout-Risiko in Summe der größere Stressfaktor sein.

Ein letzter Punkt zur Account-Konfiguration: Application Passwords. WordPress bietet seit Version 5.6 sogenannte Anwendungspasswörter, pro angebundener App ein eigenes Passwort, das ausschließlich API-Zugriff erlaubt, nicht den klassischen Backend-Login. Sinnvoll sind sie, wenn du externe Tools mit deinem Blog verbindest: eine mobile WordPress-App, ein automatisierter Pinterest-Poster, ein Newsletter-Tool, das Beiträge per API zieht. Pro Tool ein eigenes Passwort heißt: Wenn ein Tool gehackt wird oder du es nicht mehr nutzt, widerrufst du dieses eine Passwort, und der Rest deiner Konten ist davon nicht berührt.

Das Risiko: Jedes ungenutzte Application Password, das du je angelegt hast, ist ein zusätzlicher Zugangsweg in dein WordPress, der bestehen bleibt, solange du ihn nicht aktiv löschst. Schau einmal in deinem Profil unter "Anwendungspasswörter" oder "Application Passwords" nach, was da gelistet ist. Was du nicht eindeutig zuordnen kannst, also Tools, die du nicht mehr nutzt, alte Tests, Reste von Migrationen, löschst du komplett. Im Zweifel: alle deaktivieren und gezielt neu anlegen, sobald ein Tool sie wieder anfordert.

Unser Tipp: Frag dich am Ende dieser Lektion ehrlich zwei Dinge, bevor du dich an 2FA setzt, Habe ich Backup-Codes außerhalb meines Telefons, und weiß ich, wo der Wiederherstellungs-Pfad hingeht, wenn das Telefon morgen weg ist? Wenn du auf beides ohne Nachschlagen mit ja antworten kannst: 2FA aktivieren, gerne. Wenn nicht: erst die Pflicht-Schicht aus dieser Lektion sauber bauen, zwei Accounts, einzigartiges Passwort im Manager, Application Passwords aufgeräumt, und dann mit der nächsten Lektion weitermachen, in der wir an einer Stelle ansetzen, die fast alle übersehen.

Selbst mit perfektem Passwort und sauberen Rollen verrät WordPress nämlich an mehreren Stellen, wie dein Admin heißt, und solange ein Bot den Login-Namen kennt, hat er die halbe Brute-Force-Arbeit schon gespart. Wie WordPress diese Information leakt und wie du das mit Bordmitteln stillstellst, schauen wir uns als Nächstes an.