Wie ermittelt WordPress, ob ein Passwort gut ist?

WordPress zeigt bei eingegebenen Passwörtern an, ob das Passwort stark ist. Bei besonders schwachen Passwörtern muss man seit einigen Versionen mit einer Checkbox bestätigen, dass man sich des Risikos bewusst ist. Aber wie genau ermittelt WordPress denn, was „stark“ ist und was nicht? Aufgrund einer Unachtsamkeit habe ich mich auf die Suche nach der Antwort auf diese Frage begeben.

Wann ist ein Passwort sicher?

Sichere Passwörter sind ein sehr gutes Mittel, um die eigene Website sicher zu halten. Zusammen mit Backups und Updates zählen gute Passwörter zur Basis einer jeden Sicherheitsstrategie.

Was denn sichere Passwörter sind, das definieren diverse Algorithmen anders. Deswegen kann ein und dasselbe Passwort bei verschiedenen Websites und entsprechenden „Passwortstärke-Anzeigen“ sehr unterschiedlich abschneiden.

Auch WordPress hat eine solche Anzeige der Passwortstärke. Und durch eine Unachtsamkeit hat mich diese Anzeige herausgefordert.

Vorgeschichte

Ich nutze (und so soll es sein eigentlich immer sein!) für jeden Login ein anderes Passwort. Damit ich mir das nicht merken muss, nutze ich ein Programm zum Verwalten aller Passwörter. In meinem Fall ist das KeePass. Dies generiert mir auch immer neue zufällige Passwörter. Ich nutze üblicherweise 20 Zeichen lange Passwörter, die mindestens aus Groß- und Kleinbuchstaben sowie Zahlen bestehen.

Beim Anlegen eines neuen WordPress-Benutzers zeigte mir WordPress ein solches Passwort als „sehr schwach“ an. Was dahinter steckte, wollte ich gerne herausfinden.

Kurz zuvor hatte ich in Eile den Benutzer angelegt und besagtes Passwort versehentlich in das Website-Feld eingetragen statt in das Passwort-Feld. Nach dem Speichern habe ich den Fehler bemerkt und wollte ihn schnell korrigieren. Ich habe also den Eintrag aus dem Website-Feld entfernt und in das Passwort-Feld eingetragen. Tja, ich musste bestätigen, dass ich dieses sehr schwache Passwort verwenden wollte.

Ersatzweise habe ich ein neues sicheres Passwort eingetragen, welches dann auch als „sehr stark“ angezeigt wurde. Scheinbar hing es also damit zusammen, dass derselbe Wert vorher bereits im Website-Feld gespeichert war. Also habe ich mir den Quellcode genauer angesehen, um herauszufinden, was WordPress denn da alles so genau analysiert.

Vorgehensweise von WordPress

Die Passwort-Analyse erfolgt per JavaScript, weswegen sich der entscheidene Quellcode in der Datei /wp-admin/js/password-stength-meter.js findet.

Die eigentliche Analyse der Passwort-Stärke erledigt aber eine externe Bibliothek und zwar zxcvbn. Diese Bibliothek ist auf GitHub verfügbar und wurde im Rahmen einer Dropbox Hackweek erstellt.

Auf Basis dieser Bibliothek wird ein Passwort mit einem Wert zwischen 1 (sehr schwach) und 5 (sehr stark) eingestuft. Zusätzlich zu dieser allgemeinen Analyse prüft WordPress aber noch eine Blacklist ab. Und diese Blacklist ist auch der Grund für das von mir festgestellte Verhalten. Die Blacklist wird dynamisch erstellt und enthält folgende Werte:

• den Titel der Seite
• die URL der Seite
• die Werte der folgenden Felder
  • Benutzername
  • Vorname
  • Nachname
  • Spitzname
  • Öffentlicher Name
  • E-Mail
  • Website
  • Biografische Angaben
  • Titel des Blogs (wenn im WordPress-Installer aufgerufen)
  • Admin-E-Mail (wenn im WordPress-Installer aufgerufen)

Bei den o.a. Feldern wird nicht nur der aktuelle Wert ermittelt (der sich aktuell als Eingabe im Feld befindet), sondern auch der Wert, der sich beim Laden der Seite darin befand (also der Wert, der vor dem Speichern des neuen Werts noch in der Datenbank steht).

Kommt das Passwort in einem der Felder vor, wird es auch automatisch als „sehr schwach“ eingestuft. Vor der Überprüfung werden aber noch Wörter mit einer Länge bis 4 Buchstaben entfernt, um nicht zu viele „false positives“ zu erzeugen.

Und was war dann los?

Und genau dies ist mir passiert. Zum Zeitpunkt der Passworteingabe hatte ich den Wert zwar bereits aus dem Website-Feld entfernt, allerdings war das Passwort noch als alter Wert des Feldes hinterlegt, weswegen die Ermittlung der Passwortstärke hier trotzdem zuschlug.

Es geht also nicht nur darum, ein Passwort zu verwenden, was den Vorgaben der zxcvbn-Bibliothek nach „stark“ ist, sondern auch darum, dass derselbe Text nicht sonst wo in den Benutzerdaten nochmals auftaucht.