Über den guten und nicht so guten Umgang mit Passwörtern

Seit Längerem wollte ich schon über den guten und nicht so guten Umgang mit Passwörtern bzw. der Authentifizierung im Allgemeinen schreiben.
Hier sind nun meine Überlegungen, natürlich auch mit Verweisen.
Hoffentlich kann es dem einen oder anderen bei der Applikationsentwicklung und dem Umgang mit Passwörtern helfen.

Allgemein

Der Umgang mit Passwörtern kann aus mindestens zwei Perspektiven betrachtet werden.

Zum einen gibt es den Anwender, also derjenige, der ein Passwort (mehrere!) verwendet und es sich irgendwie merken muss.

Zum anderen sind es die Anwendungen bzw. deren Entwickler, die die Authentifizierung durchführen, Passwörter speichern und dafür sorgen müssen, dass gute Passwörter genutzt werden und sicher damit umgegangen wird.

Die Kriterien für den Umgang mit Passwörtern überschneiden sich teilweise bei beiden Gruppen, es gibt aber einige spezifische Kriterien.

Der Einfachheit halber habe ich hier zwei Listen für die Applikationssicht und Benutzersicht aufgestellt. Auf detaillierte Beschreibungen der Grundlagen habe ich aus zeitlichen Gründen verzichtet. Sofern keine Links dabei sind, handelt es sich um meine Erfahrungen und/oder Schlussfolgerungen.

Die Reihenfolge spiegelt keine Prioritäten wider, die kann auch je nach Anwendung und benötigter Sicherheit unterschiedlich ausfallen.

Außerdem möchte ich betonen, dass es keine absolute Sicherheit gibt. Die folgenden Punkte helfen daher, das Sicherheitsniveau zu verbessern und es möglichen Angreifern schwerer zu machen. Daneben spielt allerdings auch noch eine sorgfältige Applikationsimplementierung eine große Rolle.

Gute Passwortanforderungen aus Entwicklersicht

1. Beliebige maximale Länge (mind. 100 chars) des Passworts, es spielt für eine Hash (was hoffentlich zum Speichern genutzt wird!) einfach keine Rolle, wie lang das Passwort ist. Und viel macht das für einen Request auch nicht aus. Dafür erhöht es die potentielle Entropie und ermöglicht die Verwendung besserer Passwörter. Allgemein gilt, dass die Entropie mit der Länge des Passworts steigt, weshalb lange Passwörter/Passphrases fast immer besser sind. Jedenfalls dann, wenn es sich dabei nicht um einfach zu erratende Wörter oder Zahlen- bzw. Buchstabenkombinationen handelt. Am besten sind daher entweder Passphrases mit vielen zufälligen Wörtern oder einer ähnlich langen zufälligen Aneinanderreihung von möglichst viel unterschiedlichen Zeichen.
2. Den Anwender zur Nutzung von mindestens acht Zeichen oder besser 12 Zeichen ermutigen. Weniger als acht Zeichen sind zu wenig für ein einigermaßen sicheres Passwort, weshalb es sich anbietet, die Verwendung von mindestens acht Zeichen auch zu erzwingen. Aber man will den Anwender auch nicht vergraulen und zufällige Passwörter aus einer Vielfalt an Zeichen sind für viele Anwendungsfälle zumindest sicher genug, daher muss man unter Umständen Kompromisse machen.
3. Eine weitere häufig genutzte Methode ist es, die direkte Wiederholung von Zeichen zu verhindern oder maximal zwei bis drei Wiederholungen zu erlauben. So eine Regel soll simple Passwörter mit einfacher Zeichenwiederholung vermeiden bzw. die Komplexität erhöhen. Allerdings ist hier auch wieder Vorsicht geboten, da einige Benutzer dabei in ihrem Workflow beeinträchtigt sein könnten und manche Wörter auch mal mehrere gleiche Buchstaben hintereinander enthalten können. Daher ist es meistens besser, den Nutzer nur darauf hinzuweisen, dass das Passwort aufgrund dieser Wiederholungen schwächer ist und der Schwerpunkt das Ermöglichen einer möglichst hohen Entropie sein sollte.
4. Es kann auf den ersten Blick auch Sinn machen, Groß-/Kleinschreibung oder die Verwendung von Sonderzeichen zu erzwingen. Dabei handelt es sich jedoch auch um eine starke Einschränkung des Anwenders und kann bei diesem trotz Verwendung eines guten Passworts zu unnötigem Ärger führen. Wenn so eine Regel existiert, dann sollte es egal sein, an welcher Stelle (ja, so etwas habe ich schon erlebt...) und jeweils nur mindestens ein Mal. Der Schwerpunkt sollte aber eher auf der Länge als auf Sonderzeichen liegen. Eine Alternative ist auch hier, den User lediglich darauf hinzuweisen, dass das Passwort mit einer geringen Zeichenauswahl möglicherweise unsicher ist.
5. Ein Strength Meter kann insbesondere bei den vorherigen drei Punkten helfen. Es sollte sich in erster Linie auf die Entropie und dann auf Komplexität beziehen und möglichst vorhandene blacklists berücksichtigen. Will man auch noch sonstige prinzipiell einfach zu ratende Passwörter abdecken, wird es irgendwann ziemlich kompliziert. Solch eine Passwortbewertung sollte also gut durchdacht sein und dem Anwender möglichst viel Hilfestellung und Freiheitsgrade bei der Wahl des Passworts bieten. Allerdings sind solche Hilfen nicht unbedingt barrierefrei und funktionieren meist nicht für Nutzer, die JavaScript deaktiviert haben. Sind all diese Punkte bedacht, ist ein Strength Meter auf jeden Fall erzwungenen Regeln aus den vorherigen zwei Punkten vorzuziehen. Es lässt dem Nutzer die Freiheit und zeigt trotzdem an, ob das Passwort den Sicherheitsansprüchen genügt.
6. Keine Regeln, die bestimmte Zeichen an einer bestimmten Stelle erfordern. Das ist meiner Meinung nach eine der blödesten Möglichkeiten, die Nutzung eines sicheren Passworts zu "unterstützen". Das Gegenteil dürfte der Fall sein, besonders, wenn der User zufallsgenerierte Passwörter verwenden will.
7. Leerzeichen und mindestens kompletten ASCII Satz erlauben, gut sind auch Umlaute und Sonderzeichen oder Schriftzeichen aus einem anderen Alphabet. Abgesehen von einem etwas gründlicherem Stringhandling spricht auch absolut nichts dagegen. Dafür erhält man deutlich mehr Komplexität und damit zumindest die Grundlage für sichere Passwörter.
8. Außer für besonders sicherheitskritische Anwendungen braucht es keine Regeln, dass das Passwort nach einer bestimmten Zeit geändert werden muss. Solch eine policy führt leider oft entweder zu schlechteren Passwörtern oder das regelmäßige Vergessen durch den Benutzer. Besser ist es, ein gutes Monitoring zu implementieren und einen Hinweis zu schicken bei einem Verdacht auf Kompromittierung mit einer Anleitung bzw. einem Link zur Änderung des Passworts. Außerdem sollte dem User verdächtiges Verhalten bzw. die Anzahl der (fehlgeschlagenen) Logins angezeigt werden, damit er selbst reagieren kann. Ganz schlimm sind meiner Erfahrung nach Systeme, die die Änderung nur nach Ablauf des Passworts erlauben. Wenn schon solch eine Policy implementiert wurde oder werden muss, dann sollte man das Passwort trotzdem jederzeit ändern können.
9. Keine anti copy-paste (SSP) Regel verwenden. Wenn es dank irgendwelcher Policies doch unbedingt nötig sein sollte, dann sollte man das klar kommunizieren und nicht einfach z. B. das Eingabefeld leeren. Für Nutzer mit Passwordmanager z.B. ist das sehr umständlich. Man will das Passwort nach Möglichkeit nun mal nicht eintippen, wenn man es sich nicht merken kann und es sowieso im Manager gespeichert oder on the fly generiert wird.
10. Verwendung eines aktuellen öffentlichen hash- bzw. KDF-Verfahrens wie bcrypt, scrypt oder argon2 im Backend mit individuellen salt und möglichst hoher Iteration. Wenn man zumindest eine (gut implementierte) Kryptographie auf aktuellem Stand verwendet, sind die Passwörter selbst nach einem Hack der Anwendung noch (relativ) sicher.
11. Als Zusatz kann man auf Hilfen wie Passwort Manager oder Generatoren hinweisen. Bei der Angabe von spezifischen Tools muss die Liste allerdings regelmäßig gepflegt werden, da sich einige Programme bzw. Versionen in der Vergangenheit als unsicher herausgestellt haben.
12. Fido als "two-factor" authentication implementieren. Hier ist die Verbreitung der Endanwender noch nicht so hoch, es hilft aber für die mehr technikaffine Kundschaft. Alternativ ist die "two-factor authentication" über App oder SMS möglich. Allgemein sollte eine 2FA auf jeden Fall angeboten oder sogar als Vorgabe implementiert werden.
13. Ein sicherer "Passwort vergessen" Prozess (2FA, E-Mail Link, SMS) erleichtert dem User die Nutzung, falls er sein Passwort vergessen sollte. Sicherheitsfragen werden vom Nutzer leider meistens vergessen und sind für den Attacker häufig leicht zu schätzen.
14. Die Verwendung einer Passwort blacklist kann hilfreich sein, um User zur Verwendung von sichereren Passwörtern zu ermuntern bzw. die Verwendung von unsicheren Passwörtern zu verhindern. Hier ist aber auch wieder Vorsicht geboten, zuviele blockierte Passwörter können einen potentiellen Benutzer wiederum abschrecken.
15. Eine weitere Hilfe gegen Einbrüche ist das Reduzieren der maximalen Loginversuche innerhalb eines bestimmten Zeitraumes bzw. einer Sperrung des Accounts für einen zufälligen Zeitraum bei zuviel (z. B. 3) Fehlschlägen hintereinander.
16. Die Übertragung sollte verschlüsselt mit Hilfe von TLS/SSL erfolgen um man-in-the-middle Angriffe und das Erkennen von sensitiven Benutzerdaten wie Passwörtern zu erschweren.
    
    

Gute Passwörter aus Benutzersicht

1. Die Verwendung eines sicheren Passwort Managers und Generators ist hilfreich, bei vielen genutzten Diensten mit Authentifizierung sogar im Grunde Voraussetzung. Ein Passwort Manager deshalb, weil es das Verwalten (bzw. "Merken") der Passwörter enorm erleichtert, da man sich nicht alle Passwörter merken muss. Und ein (random) Passwort Generator, weil zufällige Passwörter tendenziell deutlich sicherer sind und zwar je mehr, desto größer die Zahl der zu Verfügung stehenden unterschiedlichen Zeichen ist. Meiner Meinung nach sollte man auf Passwort Manager ohne einen Passwortsafe zurückgreifen. Ein gut implementierter Generator mit spezifischen Salt und Masterpassphrase reduziert zumindest das Risiko, dass alle Passwörter zugänglich werden, sollte der Safe geknackt werden oder ein Bug darin für unberechtigten Zugang sorgen.
2. Zwingend ist die Regel, für jeden Dienst ein anderes Passwort bzw. Passphrase zu verwenden. Wird ein Passwort durch einen Hack oder sonstigen Zugang geknackt, so ist nur dieser eine Dienst bzw. eine Anwendung davon betroffen. Hier hilft wieder ein Passwort Manager.
3. Mindestens 12 Zeichen inklusive Sonderzeichen, Groß- und Kleinschreibung, Zahlen, Leerzeichen usw. sollten für ein zufälliges Passwort verwendet werden. Oder man verwendet lange Passphrases bzw. Diceware.
4. Die Masterphrase für einen Passwortsafe oder stateless generierte Passwörter sollte mindestens 20 Zeichen (besser deutlich mehr) haben und eine hohe Entropie aufweisen. Siehe auch der vorherige Punkt.
5. Ein Passwort für einen möglicherweise kompromittierten Dienst sollte sofort gewechselt werden. Es besteht immerhin die Chance, dass der Angreifer noch keinen Zugriff vorgenommen hat. Je schneller man reagiert, desto besser.
6. Wenn "two-factor authentication" angeboten wird (oder multiple-factor), sollte es auch verwendet werden. 2FA erhöht die Hürde für potentielle Angreifer enorm. Auch Einmalpasswörter (als 2FA) sind sinnvoll und machen es potentiellen Angreifern deutlich schwerer.
7. Ein Passwort ist nur so lange sicher, wie es nicht weitere Personen kennen. Man sollte es also nach Möglichkeit niemandem oder im Ausnahmefall nur Personen anvertrauen, denen man sehr großes Vertrauen entgegen bringt.
8. Ähnlich dem vorherigen Punkt sollte ein Passwort nirgendwo im Klartext gespeichert oder aufgeschrieben werden.
   
   

Umgang mit Accountdaten und Biometrie

1. Es kann helfen, pro Dienst eine eindeutig der Anwendung zuordenbare E-Mail-Adresse zu verwenden (die ausschließlich dort verwendet wird, z. B. dienstname@domain.tld). Neben einfacheren Filtern ist Spam auf diese Adresse ein Hinweis, dass etwas nicht stimmt. Entweder verkauft der Anbieter die Daten seiner Kunden oder jemand kam unbefugt an die Userdaten, zumindest aber die E-Mail-Adressen. Das ist besonders dann verdächtig, wenn auch der möglicherweise hinterlegte Name korrekt verwendet wird. Des Weiteren erschwert es einem möglichen Angreifer die automatische Zuordnung von Accounts bei anderen Diensten und liefert dadurch weniger Ansatzpunkte beim Knacken der Passwörter.
2. Biometrische Authentifizierung ist ein zweischneidiges Schwert. Zum einen vereinfacht es die Authentifizierung für den User enorm, sofern die nötige Hardware vorhanden ist. Man muss sich, sofern keine Kombination mit einem Passwort verwendet wird, kein Passwort merken und hat die Authentifizierungsmerkmale immer dabei. Allerdings reicht eine mangelhafte Implementierung und man kann davon ausgeben, dass es die gibt/geben wird und ein Einbruch, dann ist das genutzte Merkmal nicht mehr sicher, da es sich sogar reverse engineeren lässt. Daneben kann man Fotos bzw. einen künstlichen Fingerprint der betreffenden Personen für eine Authentifizierung nutzen. Wirklich sicher ist so eine biometrische Authentifizierung nur in Kombination mit einem Passwort. Dann fallen allerdings auch die Vorteile weg. Update 13.11.2018: Auch die Generierung von MasterPrints mittels Deep Learning (GAN) scheint hier eine Option zu sein.

Weitere Erklärungen und Argumente liefert die britische NCSC (und ja, ich weiß, dass die Teil des GCHQ sind, aber der Beitrag ist trotzdem gut!). Kommentare (derzeit noch per Mail oder twitter) sind gerne willkommen.