8 Kommentare

  1. stk at | | Reply

    Zur Ergänzung …

    in Sachen Benutzernamen:
    Der Loginname – und nur der ist für einen Angriff erheblich – wird dann nicht mehr publik, wenn in den Profileinstellungen als öffentlicher Name etwas anderes als der Wert des (nicht zu ändernden) Benutzernamens eingestellt wird. Jede Variante aus Vor-/Nachname/Nickname ist ok und bietet keinerlei Rückschlüsse für den Login. Diese Namen funktionieren auch nicht bei Brute Forces.

    Aus der Erfahrung meiner Logfile-Analysen, ebenfalls als Loginname zu vermeiden: »administrator« (nicht nur die Kurzform »admin«) und Teile des Domainnamens. Schlecht geschriebene Bruteforce-Bots probieren auch immer wieder die komplette URL, den Domainnamen ohne Subs und TLD sowie gängige eMail-Adressen wie info@… durch.

    in Sachen Passwort:
    Länge alleine reicht nicht aus. »Donaudampfschifffahrtsgesellschaft« ist zwar lang, aber durch Wörterbuch-Attacken zu kompromittieren. Idealerweise also eine wilde Mischung aus Groß- und Kleinbuchstaben sowie Ziffern. Sonderzeichen sind i.d.R. möglich, aber spätestens dann mal ein Problem, wenn man nicht seine übliche Tastaturbelegung vorfindet. »… wo war doch gleich das # auf der engl. Tastatur?!« Mit den o.g. 62 Zeichen (26 kleine + 26 große Buchstaben + 10 Ziffern) hoch 12 Möglichkeiten darf man ein Kennwort nach dem heutigen (und dem zu erwartenden) Stand der Technik als sicher bezeichnen. Wer sich’s nicht merken kann oder will, dem seien einschlägige Passwort-Manager ans Herz gelegt.

    in Sachen Sicherheitsmechanismen:
    Ein sehr wesentlicher Punkt wäre noch die SSL-Verschlüsselung mindestens des Logins, besser des Backends, idealerweise der kompletten Site. Das beste Kennwort und der verschwurbelste Benutzernamen nutzt nichts, wenn beides Klartext übermittelt und mitgesnifft werden kann. Kostenlose Certs gibt’s im Netz reichlich. Professionellere Certs (bessere Überprüfung, längere Laufzeiten, mehrere Domains oder gar Wildcards) kosten kein Vermögen mehr.

    Und natürlich endet das Thema Verschlüsselung nicht am Login-Fenster sondern sollte auch tunlichst für sFTP/FTPS gelten und eMail-Verschlüsselung umfassen, falls Kennwörter mal durch die Lande geschickt werden müssen. Auch die Pflege des heimischen Arbeitsplatzes ist nicht zu vernachlässigen: Keylogger scheren sich nicht um Verschlüsselung, sondern greifen an der Quelle ab!

    Danke für den Artikel! Man kann gar nicht oft genug wiederholen, das WordPress auch nur ein Stück Software ist, das Fehler birgt, die Angriffe ermöglicht. Und das man als Anwender durch falsche Anwendung noch ein paar Löcher dazu aufmachen kann.

  2. stk at | | Reply

    nope im Slug taucht der Nick auf – anders gesagt: wenn Du meinen Loginnamen auf meiner Testinstanz intranet.stefankremer.de findest, zahle ich beim nächsten Meetup dein Bier! ;-)

    Let’s encrypt finde ich ein sehr gutes Konzept! Da kommt hoffentlich sehr bald Bewegung in die Hosterszene. Im Moment reden die sich noch sehr gerne auf Henne/Ei raus oder versuchen darüber Geld zu generieren.

  3. stk at | | Reply

    hat mir auch keine Ruhe gelassen. Meine erste Idee, das ich durch meine Permalink-Einstellungen schon zum o.g. Verhalten komme, war’s nicht.

    Einmal mehr ist’s iThemes Security das da (dankenswerterweise) eingrätscht! Das ist bei mir schon so dermassen unter Default absortiert, dass ich das schon für Standard-WordPress Verhalten erachte.

    Konkret finden sich in der Abteilung »WordPress Tweaks« ein Haken für:

    Force Unique Nickname- Force users to choose a unique nickname
    This forces users to choose a unique nickname when updating their profile or creating a new account which prevents bots and attackers from easily harvesting user’s login usernames from the code on author pages. Note this does not automatically update existing users as it will affect author feed urls if used.

    Da sich iThemes Security auch noch diverser anderer Sicherheitsthemen annimmt, bevorzuge ich einen solchen all-in-one Schutz gegenüber div. spezialisierten Plugins, die sich ggf. auch mal funktional überschneiden können und sich dann wechselseitig eher behindern als zusammenarbeiten.

    Sorry for confusion.

  4. Johnny at | | Reply

    Ich empfehle ja immer den Login komplett zu sperren. Registrierungen oder Nutzer zuzulassen, ist bei WordPress eh immer heikel, dazu dann die potenziellen Brute-Force-Logins – kann man sich einfach sparen, indem man alles per htpasswd abriegelt.

    PS: Ich mag dein Blog Design hier sehr. Übersichtlich, clean, etwas retro, aber vor allem sehr sauber les- und scannbar. Wirklich gut gelungen :)

Einen Kommentar schreiben

WordPress-Theme realisiert von interiete.net mit Open Source