Original-URL des Artikels: https://www.golem.de/news/passwort-richtlinien-schlechte-passwoerter-vermeiden-1904-140363.html    Veröffentlicht: 08.04.2019 12:04    Kurz-URL: https://glm.io/140363

Passwort-Richtlinien

Schlechte Passwörter vermeiden

Groß- und Kleinbuchstaben, mindestens ein Sonderzeichen, aber nicht irgendeins? Viele Passwort-Richtlinien führen dazu, dass Nutzer genervt oder verwirrt sind, aber nicht unbedingt zu sichereren Passwörtern. Wir geben Tipps, wie Entwickler es besser machen können.

"Ihr neues Passwort muss zwischen 8 und 14 Stellen lang sein, Buchstaben, mindestens eine Zahl sowie mindestens ein Sonderzeichen enthalten. Sonderzeichen sind !, @, $, %, /, =, ?, `, +, ~, #, _, ., ;, :, {, }, |. Das erste Zeichen Ihres Passwortes darf kein ? oder ! Sein." So lautet die Passwort-Richtlinie beim Anlegen eines Online-Accounts bei der AOK (Rechtschreibfehler wie im Original).

Diese Passwort-Richtlinie ist sicher ein Extremfall, aber sie steht beispielhaft für etwas, das häufiger zu sehen ist: Services erwarten von ihren Nutzern, sich bei den Passwörtern an allerlei willkürliche Regeln zu halten. Viele davon sind nervig, andere sind schädlich, weil sie sicherere Passwörter verhindern. Dabei geht es besser.

Passwort-Empfehlungen des Nist für Servicebetreiber

Darüber, wie Nutzer ihre Passwörter am besten verwalten, ist in letzter Zeit viel geschrieben und gesagt worden. Eine häufige Empfehlung lautet: Ein Passwort für jeden Service, die Verwendung von Passwort-Managern und wenn möglich, die Verwendung von Zwei-Faktor-Authentifizierung.

Doch wie sollen Anbieter von Online-Services die Passwort-Problematik am besten handhaben? Dafür lohnt ein Blick in die Empfehlungen, welche die US-Standardisierungsbehörde Nist (National Institute of Standards and Technology) 2017 veröffentlicht hat. Im Rahmen der Digital Identity Guidelines gibt das Nist auf drei Seiten Ratschläge für den Umgang mit Passwörtern.

Relativ offensichtlich ist, dass es nicht sinnvoll ist, Vorgehensweisen zu verbieten, die Passwörter sicherer machen können. So sollten keine zu knappen Längenbegrenzungen vorgegeben werden - das Nist empfiehlt, dass mindestens 64 Zeichen zulässig sein sollten. Das ist aber die absolute Untergrenze, denn es kann durchaus sinnvoll sein, noch längere Passwörter zu erlauben. Wer seine Passwörter aus ganzen Sätzen konstruiert, überschreitet diese Grenze möglicherweise und wählt dabei ein vergleichsweise sicheres Passwort.

Alle Zeichen erlauben

Weiterhin sollten die möglichen Zeichen nicht eingegrenzt werden. Alles sollte erlaubt sein: Neben Groß- und Kleinbuchstaben auch Sonderzeichen, und zwar nicht nur bestimmte. Das Nist empfiehlt dabei, generell Unicode-Zeichen zu erlauben. Auch Leerzeichen sollten möglich sein.

Das Nist rät auch von vielem ab, was in der Vergangenheit üblich war. Etwa davon, spezielle Regeln für die Zusammensetzung eines Passworts zu machen. Groß- und Kleinbuchstaben oder Sonderzeichen zu verlangen, gilt demnach nicht mehr als Stand der Technik.

Denn: Rein mathematisch betrachtet ist es viel wichtiger, längere Passwörter zu wählen als Zeichen aus unterschiedlichen Zeichenklassen. Es gibt verschiedene zielführende Strategien für sichere Passwörter, und nicht alle benötigen Sonderzeichen oder Großbuchstaben. Ebenfalls rät das Nist von Richtlinien ab, die einen regelmäßigen Passwortwechsel vorsehen.

Doch wenn man diese Regeln alle weglässt - wie verhindert man, dass Nutzer besonders unsichere Passwörter wählen? Das Nist empfiehlt dazu, dass Passwörter mindestens acht Zeichen haben sollen. Dabei solle es vermieden werden, den Nutzernamen oder auch den Namen des Services selbst als Passwort zu verwenden. Des Weiteren könne das Passwort mit Wörterbuchlisten abgeglichen werden.

Bereits kompromittierte Passwörter verbieten

Die interessanteste Empfehlung ist aber, die von Nutzern gewählten Passwörter mit Listen bereits kompromittierter Passwörter abzugleichen, die bei früheren Datenlecks bekannt geworden sind. Diese Empfehlung verhindert gleich mehrere häufige Angriffsszenarien. So versuchen Angreifer oft, Accounts durch Brute-Force-Angriffe zu übernehmen und nutzen hierbei immer wieder Listen mit besonders beliebten Passwörtern.

Zudem verhindert ein solches Vorgehen zumindest teilweise sogenanntes Credential Stuffing. Das sind Angriffe, bei denen versucht wird, Zugangsdaten aus Datenlecks bei anderen Services auszuprobieren. Der Grund: Fast alle Nutzer verwenden das gleiche Passwort für viele Services. So kann es vorkommen, dass das alte Myspace-Passwort zu einem kompromittierten Account bei Facebook führt.

Wie soll ein Service eine solche Passwort-Prüfung umsetzen? Natürlich könnte er anfangen, möglichst viele im Netz verfügbare Datenbanken von früheren Datenbreaches zu sammeln. Auch kursieren in manchen Onlineforen ganze Sammlungen von kompromittierten Accountdaten, die aus verschiedenen Breaches zusammengesammelt wurden. Doch das manuelle Sammeln wäre nicht nur aufwendig, es stellen sich dabei auch einige ethische und möglicherweise rechtliche Fragen, da sich in den kompromittierten Datenbanken auch personenbezogene Daten befinden könnten.

Eine Liste mit Hashes von 500 Millionen Passwörtern

Es gibt eine einfachere Lösung: Troy Hunt, der Betreiber des Leak-Checkers haveibeenpwned.com, stellt auf seiner Webseite eine Liste mit SHA1-Hashes von aktuell über 500 Millionen geleakten Passwörtern zum Herunterladen bereit. Darin eingeflossen sind die Passwörter aus allen großen Datenleaks, die öffentlich verfügbar sind, sowie auch Datenleaks, die Troy Hunt auf verschiedene Weise erhalten hat und die nicht direkt öffentlich verfügbar sind.

Eine denkbar einfache Passwort-Richtlinie lässt sich damit umsetzen: Alle Passwörter, die schon einmal Teil eines Datenlecks waren, sind nicht erlaubt. Das gibt Nutzern immer noch einen großen Freiraum für mögliche Passwörter, doch alle besonders schlechten Varianten und alle Zugangsdaten, die leicht mittels Credential Stuffing geknackt werden können, sind ausgeschlossen.

Die Liste ist nicht gerade kurz. Gepackt sind es in der aktuellen Version 4 circa 10 Gigabyte, entpackt ist es eine 23-Gigabyte-Textdatei. Darin zu suchen geht vergleichsweise schnell: Es gibt die Hashes in sortierter Reihenfolge. Damit kann man mittels eines gegebenen Passworts einen Hash mit einer binären Suche finden. Das funktioniert in Sekundenbruchteilen. Doch nicht jeder kann oder will 23 Gigabyte für einen Passwort-Check bereithalten. Würden die reinen Hashes effizienter in binärer Form gespeichert, wären es immer noch etwa zehn Gigabyte.

Ist K-Anonymität genug?

Eine mögliche Lösung stellt Cloudflare bereit: eine Online-API, mit der die Passwörter anhand der Liste von Troy Hunt geprüft werden können. Natürlich wäre es hochgradig problematisch, alle Passwörter der eigenen Nutzer an einen von Dritten betriebenen Service zu schicken. Daher geht diese API anders vor: Sie nutzt eine sogenannte K-Anonymität.

Das Konzept dahinter ist relativ simpel. Ein Service berechnet den SHA1-Hash eines Passworts, schickt an die API aber nicht den ganzen Hash, sondern nur ein kurzes Prefix von fünf Zeichen. Die API schickt dann dem Service eine Liste aller Hashes zurück, die dieses Prefix haben. Nun kann lokal geprüft werden, ob der Hash des getesteten Passworts darunter ist.

Doch auch wenn diese Methode recht schlau ist: Manche Servicebetreiber fühlen sich sicher generell unwohl damit, Daten an Dritte zu schicken, die immer noch potenziell Rückschlüsse zulassen. Zudem ist es auch grundsätzlich sinnvoll, sich möglichst wenig von Services Dritter abhängig zu machen, wenn es Alternativen gibt. Denn natürlich kann niemand wissen, wie lange Cloudflare diesen kostenlosen Service bereitstellt.

Bloom-Filter spart Platz und ermöglicht lokalen Check

Eine Alternative, die ohne eine externe API und auch ohne die Speicherung einer riesigen Hash-Liste auskommt, sind sogenannte Bloom-Filter. Mit einem Bloom-Filter ist es möglich, eine Liste von Daten komprimiert zu speichern und dann abzufragen, ob bestimmte Daten darin enthalten sind.

Dabei müssen Kompromisse eingegangen werden, denn Bloom-Filter haben eine gewisse Fehlerwahrscheinlichkeit. Implementiert man den Passwort-Check mit einem Bloom-Filter, ist es möglich, dass in seltenen Fällen ein Passwort abgelehnt wird, das überhaupt nicht in der Liste enthalten ist. Dabei gilt: Je mehr Fehlerwahrscheinlichkeit akzeptiert wird, desto besser können die Daten komprimiert werden. Fehler gibt es nur in eine Richtung. Ein Passwort, das akzeptiert wird, ist auch mit Sicherheit nicht Teil des Bloom-Filters.

Der Softwareentwickler Hektor Martin hat eine passende Bloomfilter-Implementierung für Python unter der freien MIT-Lizenz bereitgestellt. Wird eine Fehlerwahrscheinlichkeit von 0,05 Prozent akzeptiert, benötigt der Bloom-Filter für die Passwort-Liste von Troy Hunt nur etwa ein Gigabyte. Das ist immer noch einiges, aber deutlich weniger als die gesamte Hash-Liste. Damit ist es eine sehr gute Lösung, um schlechte Passwörter abzulehnen.

Natürlich ist das Ablehnen von unsicheren Passwörtern nicht der einzige Aspekt einer sicheren Implementierung einer Nutzer-Authentifizierung. Passwörter sollten immer als Hashes gespeichert werden und zudem einen Salt nutzen. Dabei sollte eine spezielle Passwort-Hashfunktion verwendet werden. Stand der Technik ist hier Argon 2, aber auch ältere Algorithmen wie Bcrypt oder Scrypt bieten einen vergleichsweise guten Schutz.

Zudem ist es generell sinnvoll, Zwei-Faktor-Authentifizierung anzubieten. SMS als zweiter Faktor sind dabei nicht unbedingt empfehlenswert, etwas besser sind Codes nach dem TOTP-Standard, die etwa mit der Google-Authenticator-App erzeugt werden können. Am sichersten sind Hardware-Tokens, für die es seit kurzem den neuen Webauthn-Standard gibt.  (hab)


Verwandte Artikel:
Acutherm: Mit Wärmebildkamera und Mikrofon das Passwort erraten   
(02.04.2019, https://glm.io/140396 )
Datenschutz: Facebook speicherte Millionen Passwörter im Klartext   
(21.03.2019, https://glm.io/140173 )
E-Mail-Hoster: Mailbox.org kümmert sich um digitales Erbe   
(14.11.2018, https://glm.io/137710 )
App Store: Neue Entwicklerregeln verlangen iPhone-Xs-Max-Unterstützung   
(21.03.2019, https://glm.io/140161 )
Darkwallet: Kampfansage an Bitcoin-Regulierung   
(04.05.2014, https://glm.io/106235 )

© 1997–2019 Golem.de, https://www.golem.de/