Das NIST National Institute of Standards and Technology hat in den USA im Bereich der IT-Sicherheit eine mit unserem Bundesamt für Sicherheit in der Informationstechnik (BSI) grob vergleichbare Stellung: Es definiert Standards in der IT Sicherheit, die für US Behörden gelten, aber auch für stark regulierte Bereiche. Und viele Unternehmen orientieren sich an diesen Regelungen als best practice.
Nun hat das NIST ein Update seiner Digital Identity Guidelines herausgebracht, die als Special Publication 800-63 bezeichnet werden und damit in der Revision 4 vorliegen. Die letzte grundlegende Überarbeitung fand 2017 statt und es sind viel geändert. Von den 3 Bereichen der Richtlinie
- A: Identity Proofing & Enrollment
- B: Authentication & Authenticator Management
- C: Federation & Assertions
interessiert mich gerade B besonders: Hier geht es um Fragen wie Passwortsicherheit und Mehrfaktorlogins (MFA) und diese Aspekte haben eine große Rolle gespielt bei den Verbesserungen der Loginsicherheit, die wir an der Universität Bielefeld schrittweise umgesetzt haben. Und es hat sich einiges geändert:
Längere Passworte, weniger Zwänge, mehr Aufgaben für den IT-Betrieb
Zusammenfassen lassen sich die Empfehlungen so:
- Länge statt Komplexität: Passwörter sollten mindestens 15 Zeichen lang sein, wenn sie als alleiniger Authentifizierungsfaktor verwendet werden. ABER: Bei Mehrfaktor-Authentifizierung (MFA) reichen 8 Zeichen.
- Passphrasen ermöglichen: Lange Passphrasen, also Folgen von Wörtern, sind für Menschen leichter zu merken. Es sollen mindestens 64 Zeichen lange Passworte/-phrasen möglich sein.
- Keine künstlichen Komplexitätsregeln: Anforderungen an Passworte wie „mindestens ein Sonderzeichen“ oder „eine Zahl“ werden abgelehnt, da sie zu vorhersehbaren Passwörtern führen (z. B. „Passwort1!“).
- Umfangreiche Zeichensätze erlauben: Auf der anderen Seite soll es möglichst wenige Einschränkungen bei den erlaubten Zeichen geben. Die Richtlinie nennt hier Unicode.
- Kein Zwang zur anlasslosen Passwortänderung: Passwörter sollen nicht regelmäßig geändert werden, es sei denn, es gibt Hinweise auf eine Kompromittierung.
- Sperr- und Blocklisten: Passwörter sollen gegen Listen bekannter, unsicherer oder bereits kompromittierter Passwörter geprüft werden.
- Rate-Limiting: Systeme sollen Brute-Force-Angriffe durch Begrenzung der Login-Versuche verhindern.
- Keine Passwort-Hinweise oder Sicherheitsfragen: Diese sind unsicher und werden nicht mehr empfohlen.
- Mehrfaktorlogins einsetzen: Die generelle Empfehlung ist der Einsatz eines MFA Verfahrens, auch wenn dies in der unterste Stufe AAL1 noch nicht zwangsweise vorgeschrieben wird.
Das sind interessante Punkte, die wir in unserem Loginsystem zu einem großen Teil umgesetzt haben, aber es lohnt sich, sie einmal im Detail zu betrachten. In den Folgen 1048 und 1049 des Security Now Podcasts wird das Thema auch behandelt, zunächst als generelle Diskussion und dann noch in Form von Hörerfeedback.
Länge über alles
Das NIST gibt uns eine einfache Regel an die Hand: Bei einem Passwort kommt es letztlich (fast) nur auf die Länge an. Den Punkt hatte ich schon mal in dem Blogpost ‚Passworte richtig hashen‚ angerissen, dort aus der Sicht eines Systembetreibers, der sich auf den Fall vorbereiten muss, dass die gesamte Passwortdatenbank abhanden kommt: Abgesehen von der Art des Hashverfahrens hängt es entscheidend von der Länge der zu knackende Passworte ab, wie aufwändig es für einen Angreifer ist die Passworte im Klartext zu erhalten. Diese simple Einsicht ist auch der Kern von Steve Gibsons Password Haystack, der demonstriert, wie schnell die Komplexität mit wachsender Passwortlänge steigt.
Geben: Keine Komplexitätsregeln mehr
Das NIST nimmt nun die Empfehlung zurück Regeln zur Passwortzusammensetzung (‚mindestens ein Kleinbuchstabe, ein Großbuchstabe, eine Ziffer, ein Sonderzeichen‘) durchzusetzen. Die durch Forschungsergebnisse bestätigte Erkenntnis ist, dass diese Regeln nicht zu besseren Passworten führen, sondern zu vorhersagenbaren Abwandlungen schlechter Passworte (aus ‚passwort‘ wird dann z. B. ‚Passw0rt!‘).
Nehmen: Größere Passwortmindestlänge
Die nun geforderte Passwortmindestlänge beträgt 15 Zeichen – zumindest wenn kein Mehrfaktorlogin eingesetzt wird. Im Loginsystem sollen daher lange Passworte oder Passphrasen möglich werden, also auch ganze Sätze, die sich im Gegensatz zu zufällig generierten Passworten dann auch wieder merken lassen. Das NIST fordert hier die Zulässigkeit von mindestens 64 Zeichen langen Passworten.
Die Richtlinie befasst sich auch kurz mit der Frage, warum man überhaupt eine Begrenzung der Passwortlänge haben sollte: Hier spielen letztlich Erwägungen beim Betrieb des Loginsystems eine Rolle: Wenn ich keine Begrenzung habe, dann können Angreifer das System um so leichter mit riesigen Datenmengen überfluten, während es für die Loginsicherheit keinen wirklichen Gewinn bringt.
Für einen realen Einsatz, der aus Sicht der Nutzer*innen ‚unbegrenzte‘ Passworte erlaubt, würde eine Grenze z. B. bei 1.000 Zeichen vermutlich völlig ausreichen. Aber Achtung: Je nach eingesetztem Hashverfahren – z. B. bcrypt – muss man hier ein Weg finden mit ggf. vorhandenen, technischen Einschränkungen umzugehen.
Emojipassworte
Für die Implementierung im Loginsystem herausfordernd kann auch die Vorgabe sein, einen sehr großen Zeichensatzumfang zu erlauben. Wenn man in Passworten Unicode ermöglicht sind interessante Passphrasen möglich (‚Erst nach dem ersten ☕ den 💻 öffnen!‘) und die Anzahl der möglichen Passworte erhöht sich dramatisch. Auch erlaubt es Nutzer*innen, deren Muttersprache nicht das lateinische Alphabet verwendet, ein Passwort in ihrer Sprache, was gerade bei einer Passphrase wichtig ist.
Sichergestellt sein muss dann aber, dass alle Teile des Loginsystems mit so einem erweiterten Zeichensatz korrekt umgehen können. Gerade in IT-Landschaften, in denen ‚Single Sign-on‘ noch bedeutet, dass das gleiche Passwort in die individuellen Loginmasken unterschiedlicher Anwendungen eingetragen wird, kann dies eine hohe Hürde sein.
Ein Ende des Zwangs zu Passwortänderungen
Wenn man recherchiert, woher eigentlich die Idee stammt es könnte die IT-Sicherheit erhöhen seine Nutzer*innen dazu zu zwingen regelmäßig ihre Passworte zu ändern, dann landet man oft in den 80er oder gar 70er Jahren, also in der Anfangszeit der IT. Dies ist vermutlich das Beispiel einer Idee, die auf anekdotischer Evidenz basierend entstand und sich dann in Vorgaben z. B. des NIST manifestierte und zu Dingen wie dem ‚Ändere-dein-Passwort‘-Tag geführt haben. Und vielleicht zu dem stärksten Grund, warum die IT-Abteilung im Bereich der IT-Sicherheit manchmal von den Betroffenen gehasst wird. Denn es passt einem ja eigentlich nie, wenn man dazu gezwungen wird mal wieder sein Passwort zu ändern.
Auch hier gibt es inzwischen die Erkenntnis das dieser Zwang nicht zur Erhöhung der Sicherheit führt, denn die meisten Nutzer*innen werden einfach eine Abwandlung ihres bisherigen Passworts verwenden. Oder versuchen das System auszutricksen, damit sie dann wieder ihr altes Passwort verwenden können. Oder sich das neue, noch nicht gemerkte Passwort irgendwo aufschreiben, z. B. auf einem Postit unter der Tastatur.
Als Grund für regelmäßige Passwortänderungen wird oft die Eindämmung von bereits erfolgten Passwortdiebstählen aufgeführt. Aber dieses Argument ist gerade im Unternehmensumfeld höchstens eine Entschuldigung für ansonsten unzureichende Sicherheitsmaßnahmen:
- Ein Passwortdiebstahl wird heute sehr rasch ausgenutzt, teilweise vollautomatisiert und innerhalb von Sekunden. Eine erzwungene Passwortänderung einige Monate später kommt da viel zu spät, hier müssen andere Mechanismen dabei helfen so einen Fall schnell zu entdecken.
- Im privaten Umfeld ist es wichtiger individuelle Passworte für alle Dienste zu verwenden, damit der Diebstahl des Logins bei einem Dienst nicht gleich alle anderen genutzten Dienste ebenfalls kompromittiert. Auch hier macht einen die anlasslose Änderung aller Passworte nicht sicherer.
Mehr Aufgaben für den IT-Betrieb bei der Passwortsicherheit
Unseren Nutzer*innen können wir also etwas geben, was sie sehr freuen wird. Aber dafür schreibt das NIST uns IT-Verantwortlichen einiges ins Aufgabenheft, dass gar nicht mal so trivial in der Umsetzung ist:
Schutz vor Brute-Force-Angriffen
Ein Argument für komplexe Passwortregeln war es bisher, dass dadurch Versuche Passworte durch massenhafte Rateversuche herauszufinden nicht (so schnell) erfolgreich sind. Dabei geht es nicht so sehr darum, dass jemand die ganze, gehashte Passwortdatenbank entwendet, sondern das es möglich ist am Loginsystem selbst viele Passworte zu testen.
Aber eigentlich war es immer schon absurd, dass Loginsysteme so etwas zugelassen haben: Es ist schlicht der Bequemlichkeit von uns IT-Systembetreibern geschuldet, dass wir unseren Nutzer*innen einen sehr großen Teil der Aufgabe zugeschoben haben, ihre Logindaten sicher zu halten, weil es sehr einfach ist eine Loginmaske online zu stellen, die stumpf und mit maximaler Systemleistung eine Passwortprüfung ausführt.
Ein Loginsystem zu bauen, das in der Lage ist Angreifer wirkungsvoll daran zu hindern mit Vollgas Passworte durchzuprobieren, ohne dabei eine Tür für DoS Angriffe zu öffnen, ist hingegen durchaus komplex, selbst IT Giganten scheitern daran immer wieder. Zum Beispiel Microsoft in der AuthQuake genannten Sicherheitslücke, auch wenn es hier um die Validierung von TOTP Codes ging.
Nun schreibt das NIST effektive Maßnahmen für eine Ratenbegrenzung (Throttling) vor und gibt damit einen großen Teil der Verantwortung für die Passwortsicherheit an den IT-Betrieb zurück.
Ein Punkt, mit dem ich dabei nicht einverstanden bin, ich der Vorschlag IT-Konten bzw. einen Authenticator wie ein Passwort nach z. B. 100 Fehlversuchen dauerhaft zu sperren. Darin liegt immer die Gefahr von Denial-of-service Angriffen: Jemand kann mit einem kleinen Script nach und nach die gesamte Nutzerschaft aussperren und so eine Organisation lähmen.
Das NIST Papier adressiert dieses Risiko und schlägt z. B. vor, dies durch Verzögerungen bei Loginversuchen zu begrenzen und mit Optionen sich als Nutzer*in z. B. per E-Mail wieder selbst freizuschalten eine Selbstheilung zu ermöglichen.
Im Unternehmenkontext ist aber das E-Mailkonto vielleicht Teil des angegriffenen Systems und damit nicht mehr zugänglich nach einer Sperrung. Die Implementierung, die wir an der Universität gewählt haben, führt daher nur temporäre Loginsperren aus. Damit lässt sich die Anzahl der möglichen Passwortrateversuche / Minute genau einstellen auf ein Maß, welches als vertretbar eingeschätzt wird. Zusätzlich werden die Nutzer*innen darüber informiert und können z. B. Maßnahmen ergreifen, wie die Wahl eines noch sichereren Passworts.
Sperr- und Blocklisten verwenden
Das Wegfallen von Passwortkomplexitätsregeln soll nicht dazu führen, dass wieder komplett triviale Passworte möglich werden. Denn solche Passworte sind in zahlreichen Datendiebstählen enthalten und werden deshalb besonders oft in Angriffen verwendet, die man als Credential Stuffing oder Password Spraying bezeichnet.
Es gibt große Sammlungen von gestohlenen Passworten, der Have I been pwned (HIBP)-Dienst ist vielleicht der bekannteste. In diesem Blogpost haben wir einmal ausführlich beschrieben wie er funktioniert und wie man ihn im eigenen Loginsystem nutzen kann.
Die Umsetzung ist nicht völlig trivial, da man auch hier über Punkte wie die Performance und Abhängigkeiten von internen oder externen Services nachdenken muss. Im Idealfall werden Passworte bei jedem Login geprüft, so dass sich Änderungen an der Sperrliste direkt auswirken können, und nicht erst bei Passwortänderungen, die ja nur noch selten vorkommen sollen. Zusätzlich sollen Passworte mit Bestandteilen gesperrt werden, die Bezug zur Organisation oder zur fraglichen Anwendung haben.
Warum noch Passworte, wenn man eine MFA hat?
Bei den ganzen Aufwänden, die es kostet Passworte sicher zu halten, könnte man sich fragen warum man sich noch damit herumschlagen sollte, wenn man sowieso eine MFA Lösung plant? Hier sieht die NIST Richtlinie Passworte zumindest als Übergangstechnologie an, die im Dreiklang der Authentifizierung, in der im Idealfall diese 3 Elemente notwendig sind, den ersten Punkt abdeckt:
- Something You Know (Passwort, PIN).
- Something You Have (Hardware-Token, Smartphone).
- Something You Are (Biometrie wie Fingerabdruck).
Und da wohl nahezu alle existierenden Loginsysteme von einer Passwortlösung aus starten, die dann um ein MFA Verfahren wie FIDO Tokens ergänzt wird, sind sie der Ausgangspunkt, der vielleicht in den kommenden Jahren durch Passkeys oder etwas vergleichbares nach und nach abgelöst wird.
Fazit: Es geht in Richtung von Single Sign-on Lösungen
Aus Sicht unserer Nutzer*innen haben die nun vom NIST empfohlenen Regelungen etwas positives: Endlich keine enigmatischen Regeln zur Passwortzusammensetzung und erst recht kein erzwungener Wechsel eines guten Passworts, welches man sich gemerkt hat. Und auch die Option eine MFA Einführung damit versüßen zu können, dass die Passwortlänge dann auf 8 Zeichen reduziert werden darf, ist ein interessanter Aspekt, der einem IT-Betrieb Freunde machen kann.
Auf der anderen Seite wächst die Komplexität eines nach den NIST Vorgaben arbeitenden Loginsystems deutlich: Schutz vor Brute-Force-Angriffen, ohne DoS Angriffe zu ermöglichen, Prüfung von Sperrlisten und natürlich die MFA Integration sind alles Punkte, die Arbeit machen. Arbeit, die man nicht bei jeder der zahlreichen Anwendungen im Unternehmen erneut haben will.
Wer jetzt noch keine Single Sign-on Lösung hat – SSO meint hier, dass die Nutzer*innen sich an einem zentralen Identity Provider anmelden, der ein Logintoken an angeschlossene Systeme weitergibt – der sollte damit nun anfangen. Die dafür ggf. notwendigen Kosten lassen sich nun noch mehr rechtfertigen.
Und ein gut funktionierendes SSO System ist ebenfalls etwas, wofür einem IT-Betrieb die Nutzerschaft sehr dankbar sein wird, selbst wenn bei der Gelegenheit die Sicherheitsanforderungen in die Höhe geschraubt werden.
