Wor­d­Press-Log­in schüt­zen

 

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.

Wor­d­Press über­prüft die Sicher­heit von neu­en Pass­wör­tern direkt bei Pass­wort­wech­sel.

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 wer­den.

Weni­ger siche­re Pass­wör­ter soll­ten von Wor­d­Press auto­ma­tisch abge­lehnt wer­den.

Dies kann durch klei­ne Anpas­sun­gen oder durch fer­ti­ge Wor­d­Press-Plugins rea­li­siert wer­den.

 


 

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 wer­den.

„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 wer­den.

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

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ög­lich:

API von Troy Hunt (Anlei­tung)

Auch für die­se Funk­ti­on kön­nen fer­ti­ge Wor­d­Press-Plugins genutzt wer­den.

 

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

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 ver­wen­det.

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 wer­den.

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

„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 Plugins bereit.

 


 

Ser­ver­sei­ti­ge Absi­che­rung

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

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 Wor­d­Press erreicht wer­den kann.

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

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 Kun­den­be­reich).

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 ver­tre­ten.

 

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

Pass­wort­da­tei gene­rie­ren:

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 wer­den.

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 Wor­d­Press-Instal­la­ti­on abge­legt.

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

 

.htac­cess anpas­sen

Jetzt wird der fol­gen­de Code ganz am Ende der .htac­cess ein­ge­fü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 wer­den
<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-For­ce- und Wör­ter­buch­an­grif­fe

Schutz per Java­Script

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

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 wer­den.

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

Auch hier­für kann auf fer­ti­ge Plugins zurück­ge­grif­fen wer­den.

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

Häu­fig wer­den Plugins 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 gestar­tet.

 

XMLRPC-Schnitt­stel­le deak­ti­vie­ren

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

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ön­nen.

Das ermög­licht rela­tiv effi­zi­en­te Bru­te-For­ce-Angrif­fe auf die­se Schnitt­stel­le.

Aus die­sem Grund ist es emp­feh­lens­wert, die Schnitt­stel­le kom­plett zu deak­ti­vie­ren.

 

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 Apa­che):

<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 Wor­d­Press deak­ti­viert und der RSD-Link aus dem HTML-Hea­der ent­fernt wer­den:

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