Passwortregeln für Administratoren – Umdenken!

Passwortregeln sind auch für Administratoren und Entwickler wichtig. Denn neben Anwendern können natürlich auch Administratoren und Entwickler jede Menge Fehler machen, wenn es um Passwörter geht. Bei der Entwicklung oder Administration von Systemen müssen Regeln für Passwörter erstellt und umgesetzt werden. Aber welche Regeln sind die richtigen?

Welches die häufigsten Fehler sind, und wie man diese vermeiden kann, soll Thema in diesem Beitrag sein. Dabei greife ich auch Ideen auf, die aktuell in einem Arbeitskreis der NIST zum Thema Passwörter diskutiert werden. Die Ideen dürften auch dem ein oder anderen Anwender gefallen. Es lohnt sich also mal darüber nachzudenken.

Passwortlänge nicht durch Passwortregeln begrenzen

Die Nutzer sollten in der Länge der Passwörter nie begrenzt werden. Es ist offensichtlich, dass die Qualität eines Passwortes mit der Länge erheblich steigt. Leider gibt es nach wie vor Systeme, Applikationen oder auch Administratoren, die die maximale Länge festsetzen. Dafür gibt es keine einleuchtende Begründung.

Im Gegenteil, wenn Anwender gezwungen sind ein Passwort mit zehn oder mehr Zeichen zu verwenden, kann auf Komplexitätsanforderungen in den Passwortregeln (Sonderzeichen & Co.) verzichtet werden.

Blacklisting einführen

Wann immer möglich, sollte eine „Blacklist“ eingeführt werden. Diese Liste mit den 1 Million beliebtesten Passwörtern der Welt sollte für die Nutzer verboten werden. Das ist aber nur sinnvoll, wenn Anwender bei Passwortvergabe auf die Blacklist hingewiesen werden!

Fallback Szenarien (Recovery) absichern

Manche Systeme bringen Funktionen zum Passwort Recovery mit. Am beliebtesten sind Verfahren wie „Kennworthinweise“, welche der Benutzer selbst bei Passwortvergabe festlegen kann. Auch gerne genommen werden die berüchtigten Sicherheitsfragen (wie ist der Mädchenname ihrer Mutter, welches war ihr erstes Haustier, etc.). Solche Funktionen sind außerordentlich leicht zu knacken und sollten unbedingt abgeschaltet werden. Wie einfach das geht, hat 2015 ein Teenager gezeigt, indem er sich in den Mailaccount des CIA Direktors gehackt hat. Muss zwingend ein Recovery Verfahren verfügbar sein, so ist ein telefonisches Verfahren (bspw. mittels Challenge-Response) zu empfehlen. Auch hier kann ein Angreifer eine falsche Identität vortäuschen, also sind dabei zusätzliche Maßnahmen zu ergreifen.

Keine Einschränkung im Zeichensatz

Warum es Systeme gibt, die Leerzeichen nicht als Teil eines Passwortes sehen, konnte ich bislang nicht ermitteln. Tatsächlich gibt es (alte) Hashverfahren, die damit nicht umgehen können und Leerzeichen vor der Erstellung der Hashes entfernen. Dadurch werden Passwörter unnötig geschwächt, weil die Länge reduziert wird. Natürlich sind Nutzer (insbesondere internationale Anwender) darauf hinzuweisen, dass bestimmte Sonderzeichen in anderen Tastaturlayouts auf anderen Tasten liegen. Man sollte aber nie die Anwender für unfähig halten und so deren Möglichkeiten direkt in den Passwortregeln einschränken.

Komplexitätsanforderungen in Passwortregeln durch Längenanforderungen ersetzen

Der Zwang Passwörter mit hohen Komplexitätsanforderungen zu fordern, führt zu unsicheren Passwörtern. Wenn die Anforderung (wie heute üblich) so aussieht: das Passwort muss mindestens acht Zeichen lang sein, es muss Groß- und Kleinbuchstaben sowie mindestens eine Zahl und ein Sonderzeichen enthalten, es darf keine einfachen Muster (asdf, etc.) enthalten, es darf nicht mit den letzten sechs verwendeten Passwörtern übereinstimmen und es muss spätestens nach 60 Tagen gewechselt werden, dann passiert es schnell, dass Anwender regelmäßig ihr aktuelles Passwort vergessen oder ein Muster entwickeln (Frühjahr2017!, Sommer2017!, Herbst2017!, etc.) oder das Passwort auf dem berühmten Post-it am Monitor landet. Also ganz klar: weg mit den Komplexitätsanforderungen in Passwortregeln, hin zu langen Passwörtern!

Nutzung sicherer Hashes mit Salt

Leider sieht man sehr häufig, dass Passwörter in Benutzerdatenbanken entweder gar nicht verschlüsselt oder mit schlechten Hash-Verfahren ohne Salt abgelegt werden. Das ist ein absolutes NoGo auf Seite der Entwickler und Administratoren. Wer nicht sicher ist, welche Hashverfahren als sicher einzustufen sind, sollte sich hier beim BSI informieren. Wie oft Passwörter unverschlüsselt im Klartext abgelegt sind, lässt sich beispielsweise hier nachvollziehen. Von 3,4 Mrd. Accounts, die gebreached wurden, sind knapp 1,7 Mrd. mit plaintext Passwörtern veröffentlicht worden. Ein häufig ebenso unterschätztes Problem: Microsoft Active Directory! Viele Administratoren schrecken davor zurück die sog. „Funktionsebene“ der Domain anzuheben. Das liegt daran, dass sich dieser Vorgang nicht umkehren lässt. Ist dann aber diese Funktionsebene auf dem Niveau „Kompatibel zu Windows XP“, so bedeutet dies, dass für alle Konten, neben den als sicher geltenden NTLMv2 Hashes, auch LM-Hashes abgelegt werden. Und LM-Hashes (ein Hashverfahren aus Windows NT 3.x Zeiten) sind heutzutage binnen Millisekunden geknackt. Also ist es wichtig sichere Verfahren, wie SHA-256 zu verwenden.

Um diese Sicherheit zu erhöhen, sollten die Hashes mit Salt versehen werden. Somit werden Wörterbuchattacken auf gestohlene Passworthashes quasi unmöglich und dem Angreifer bliebe nur noch Brute Force. Die Benutzung von Salted Hashes hat dabei keinerlei messbare Zusatzbelastung für solche Systeme. Warum also auf das Salz in der Suppe verzichten?

Kein Zwang zum Wechsel

Wenn das System, welches Sie betreuen oder entwickeln, alle Forderungen dieses Beitrags unterstützt, insbesondere die Nutzung sicherer Hashverfahren mit Salt und lange Passwörter, dann kann der erzwungene Wechsel getrost über Bord geworfen werden. Damit wäre nämlich nur ein Brute-Force-Angriff auf den Hash erfolgreich. Da dieser bei guten Verfahren und Passwörtern mit mehr als zehn Zeichen über 5.000 Jahre dauert, ist der Ablauf von Passwörtern überflüssig. Man erspart den Anwendern sich Muster auszudenken oder ein Post-it an den Bildschirm zu kleben.

Fazit

So schnell werden wir die leidigen Passwörter wohl nicht los. Wer aber Systeme entwickelt oder betreut, die durch Passwörter geschützt werden, der sollte sich die grundlegenden Gedanken machen und für seine Anwender die richtigen Entscheidungen treffen.

1 Kommentar

  1. Hallo Herr Weinmann,

    Ihr Artikel gefällt mir gut und ich stimme fast allen Punkten ohne Einschränkung zu. Lediglich beim Zwang zum Wechsel habe ich eine andere Meinung. So hilft das Passwortwechseln nicht nur, die Zeitspanne für den Cracker zu verkürzen, sondern auch, das Angriffsfenster für ein auf anderen Wegen kompromittiertes oder erbeutetes Passwort zu verkürzen. Und die letzte Gefahr können Sie durch ein langes Passwort nicht entschärfen.

    Und noch ein Hinweis: in der c’t 03/2013 ist zu diesem Thema vor einiger Zeit einmal ein sehr schöner Grundlagenartikel mit dem Titel „Knack mich, wenn Du kannst“ erschienen, kostenlose unter https://www.heise.de/ct/ausgabe/2013-3-Die-Tools-und-Techniken-der-Passwortknacker-2330451.html abrufbar ist.

    Viele Grüße
    Volker Scholz

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

CAPTCHA *