Word­Press-Log­in schützen

Ver­öf­fent­licht am 1.2.2019

Pass­wort­si­cher­heit

Jeder Benut­zer soll­te sein Pass­wort selbst ändern kön­nen, damit auf einen Pass­wort­dieb­stahl sofort reagiert wer­den kann.

Word­Press über­prüft die Sicher­heit von neu­en Pass­wör­tern direkt bei Passwortwechsel.

Damit alle Benut­zer tat­säch­lich siche­re Pass­wör­ter ver­wen­den, soll­ten aus­schließ­lich Pass­wör­ter der höchs­ten Sicher­heits­stu­fe akzep­tiert werden.

Weni­ger siche­re Pass­wör­ter soll­ten von Word­Press auto­ma­tisch abge­lehnt werden.

Dies kann durch klei­ne Anpas­sun­gen oder durch fer­ti­ge Word­Press-Plug­ins rea­li­siert werden.

 

 

Pass­wort­da­ten­bank­ab­gleich

Zusätz­lich soll­te über­prüft wer­den, ob Pass­wör­ter bereits von einem Daten­leck betrof­fen waren und in einer der ein­schlä­gi­gen Pass­wort­samm­lun­gen geführt werden.

„Neue Pass­wort-Leaks: Ins­ge­samt 2,2 Mil­li­ar­den Accounts betrof­fen” (Hei­se-Online)

Die­se Emp­feh­lung beruht auch auf der aktu­el­len NIST-Richt­li­nie (Natio­nal Insti­tu­te of Stan­dards and Tech­no­lo­gy).

Es ist davon aus­zu­ge­hen, dass öffent­lich bekann­te Pass­wör­ter von Cra­ckern bevor­zugt getes­tet werden.

Aus die­sem Grund soll­ten sol­che Pass­wör­ter nicht mehr ver­wen­det werden.

Um dies zu über­prü­fen ist z.B. ein auto­ma­ti­sier­ter Abgleich mit der Daten­bank von Troy Hunt über die API möglich:

API von Troy Hunt (Anlei­tung)

Auch für die­se Funk­ti­on kön­nen fer­ti­ge Word­Press-Plug­ins genutzt werden.

 

Als Alter­na­ti­ve dazu ist ein loka­ler Abgleich der Daten mit dem Python-Script bloom.py möglich:

bloom.py (github.com)

Gestar­tet wird das Script wie folgt:

python bloom.py test -s pwned-passwords-2.0.bloom Passwort

 

 

Zwei-Fak­tor-Authen­ti­sie­rung (2FA)

In der Pra­xis wer­den häu­fig die sel­ben Pass­wör­ter oder nur gering­fü­gig abge­wan­del­te Pass­wör­ter für unter­schied­li­che Accounts verwendet.

Mehr­fach ver­wen­de­te Pass­wör­ter kön­nen durch ein Daten­leck eines ande­ren Diens­tes unbe­merkt zum Sicher­heits­ri­si­ko werden.

Aus die­sem Grund soll­te für den Word­Press-Log­in eine Zwei-Fak­tor-Authen­ti­sie­rung (2FA) ver­pflich­tend ein­ge­rich­tet werden.

„Zwei-Fak­tor-Authen­ti­sie­rung für höhe­re Sicher­heit” (BSI)

Auch hier­für ste­hen ent­spre­chen­de Plug­ins bereit.

 

 

Ser­ver­sei­ti­ge Absicherung

Ein guter Schutz des Word­Press-Log­ins lässt sich durch eine (zusätz­li­che) ser­ver­sei­ti­ge Pass­wort­ver­ga­be realisieren.

Dabei muss der Benut­zer sich zunächst durch ein Pass­wort gegen­über dem Ser­ver authen­ti­fi­zie­ren, bevor der eigent­li­che Log­in-Bereich von Word­Press erreicht wer­den kann.

Ziel ist ein Log­in-Schutz, der von Word­Press-Sicher­heits­lü­cken unab­hän­gig ist. Dar­über hin­aus kön­nen Fehl­an­mel­dun­gen (und damit ggf. Bru­te-Force-Angrif­fe) res­sour­cen­scho­nen­der ver­ar­bei­tet werden.

Lei­der sind bei die­sem Ver­fah­ren zwei Pass­wort­ein­ga­ben nötig. Dar­über hin­aus las­sen sich die ser­ver­sei­ti­gen Zugän­ge nur von einem Admi­nis­tra­tor des Ser­vers  ein­rich­ten und kön­nen von den Benut­zern nicht geän­dert wer­den (auch exis­tiert kei­ne „Pass­wort vergessen”-Funktion).

Aus die­sem Grund eig­net sich die­ses Ver­fah­ren nur für klei­ne Web­sites (z.B. ohne Kundenbereich).

Auch ist das Ver­fah­ren eher für klei­ne Unter­neh­men geeig­net, bei denen die Web­site nur von weni­gen, immer glei­chen Per­so­nen ver­wal­tet wird.

Bei grö­ße­ren Ein­hei­ten ist die Kom­fort­ein­bu­ße durch das zusätz­li­che Pass­wort i.d.R. nicht zu vertreten.

 

Anlei­tung für einen zusätz­li­chen Pass­wort­schutz per .htac­cess für den Apache:

Pass­wort­da­tei generieren:

Zunächst wer­den die gewünsch­ten Benut­zer­zu­gän­ge mit den zuge­hö­ri­gen Pass­wör­tern defi­niert. Auf die­ser Basis wird der Inhalt für die  .htpasswd gene­riert. Dies kann online mit dem Pass­wort­ge­ne­ra­tor auf aspirine.org erle­digt werden.

Ein­stel­lun­gen:

  • bcrypt, Cost 11
  • Wich­tig Aus Benut­zer­na­men und Pass­wort soll­te nicht der Ein­satz­ort der gene­rier­ten .htpasswd abge­lei­tet wer­den kön­nen (die Domain soll­te nicht ent­hal­ten sein)

Online-Pass­wort­ge­ne­ra­tor (aspirine.org)

.htpasswd erstel­len

Nun wird eine Text­da­tei mit dem Namen .htpasswd erstellt und die gene­rier­ten Inhal­te wer­den ein­ge­fügt. Die­se Datei wird dann im Haupt­ver­zeich­nis der Word­Press-Instal­la­ti­on abgelegt.

Dabei ist zu beach­ten, dass Apa­che berech­tigt sein muss, die­se Datei zu lesen.

 

.htac­cess anpassen

Jetzt wird der fol­gen­de Code ganz am Ende der .htac­cess eingefügt:

Ein­stel­lun­gen:

  • /pfad/zur/datei/ muss natür­lich an den „ech­ten” Ver­zeich­nis­pfad auf dem Ser­ver ange­passt werden
<Files wp-login.php>
   AuthType Basic
   AuthName "Bitte anmelden"
   AuthUserFile /pfad/zur/datei/.htpasswd
   Require valid-user
</Files>
<FilesMatch "(\.htaccess|\.htpasswd)">
   Require all denied
</FilesMatch>

 

Zusätz­li­cher Schutz gegen Bru­te-Force- und Wörterbuchangriffe

Schutz per JavaScript

Zusätz­lich zu den o.g. Maß­nah­men kann ein Java­Script-Schutz hin­zu­ge­fügt werden.

Dabei lässt sich ein Log­in nur erfolg­reich durch­füh­ren, wenn Java­Script inter­pre­tiert wird. Dies kann bei­spiels­wei­se durch das Set­zen eines Hakens abge­fragt werden.

Die­ser Schutz kann gegen auto­ma­ti­sier­te Cra­cker schüt­zen, die Java­Script nicht interpretieren.

Auch hier­für kann auf fer­ti­ge Plug­ins zurück­ge­grif­fen werden.

Limi­tie­rung der Log­in-Ver­su­che (Cool Down)

Häu­fig wer­den Plug­ins emp­foh­len, die IP-Adres­sen zeit­wei­se sper­ren, von denen fehl­ge­schla­ge­ne Log­in-Ver­su­che aus­ge­gan­gen sind.

Dies kann jedoch nicht gegen pro­fes­sio­nel­le Angrif­fe schüt­zen, weil die­se i.d.R. von sehr vie­len IP-Adres­sen aus­ge­hen. Dabei wer­den von jeder IP-Adres­se nur 1–2 Log­in-Ver­su­che gestartet.

 

XMLRPC-Schnitt­stel­le deaktivieren

Über die XMLRPC-Schnitt­stel­le (xmlrpc.php) ist eben­falls eine Anmel­dung am Sys­tem möglich.

Beson­ders kri­tisch ist die Mög­lich­keit, pro Anfra­ge sehr vie­le Pass­wör­ter gleich­zei­tig anfra­gen zu können.

Das ermög­licht rela­tiv effi­zi­en­te Bru­te-Force-Angrif­fe auf die­se Schnittstelle.

Aus die­sem Grund ist es emp­feh­lens­wert, die Schnitt­stel­le kom­plett zu deaktivieren.

 

Dabei soll­te die Datei xmlrpc.php ser­ver­sei­tig vor Zugrif­fen von außen geschützt wer­den (Code­bei­spiel per .htac­cess für den Apache):

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Durch einen Ein­trag in der functions.php kann zusätz­lich die XMLRPC-Schnitt­stel­le in Word­Press deak­ti­viert und der RSD-Link aus dem HTML-Hea­der ent­fernt werden:

/* XMLRPC-Schnittstelle deaktivieren */
add_filter( 'xmlrpc_enabled', '__return_false' );
/* Link aus dem HTML-Header entfernen */
remove_action('wp_head', 'rsd_link');