Authentifizierung per Passwort: Totgesagte leben länger

Es ist eine Binsenweisheit: Die Authentifizierung per Passwort birgt viele Nachteile, ist aber nicht totzukriegen. Was ist eigentlich so schlecht an der Authentifizierung per Passwort und was kann man besser machen?

Einführung

Wer eine bestimmte Ressource verwenden möchte, muss zunächst beweisen, dass er dazu auch berechtigt ist. Das gilt in der realen Welt ebenso wie bei der Nutzung von Computersystemen.

In der realen Welt passiert dies oft dadurch, dass man den Schlüssel zu einem Lagerraum besitzt oder einen Ausweis vorzeigen muss, bevor man eingelassen wird. Beide Fälle haben gemeinsam, dass man Kraft seiner Rolle in den Besitz eines Gegenstandes (Schlüssel beziehungsweise Ausweis) gelangt ist, der den Zugriff auf die gewünschte Ressource erlaubt. Ein Angreifer müsste einen solchen Gegenstand fälschen, um unberechtigt an die Ressourcen zu gelangen. Um dies so schwer wie möglich zu machen, haben sowohl Schlüssel als auch Ausweis verschiedene Sicherheitsmerkmale, die ohne spezielles Werkzeug oder Kenntnisse nur schwer nachzumachen sind. In der fundamentalen Klassifizierung von Authentifizierungsmethoden handelt es sich in beiden Fällen um den Besitz von etwas, anhand dessen man authentifiziert werden kann.

Alternativ zum Besitz können biometrische Merkmale der Authentifizierung dienen. Diese gehören zu der Person selbst, die Authentifizierung basiert auf Inhärenz. Beispiele dafür sind Netzhautscanner oder Fingerabdruckscanner, die inzwischen nicht nur Türen öffnen, sondern auch an Computer angeschlossen zur Entsperrung genutzt werden können. Der größte Vorteil biometrischer Merkmale ist, dass man diese zur Authentifizierung immer dabei hat. Der Nachteil ist, dass diese Merkmale im Falle einer Kompromittierung nicht neu ausgegeben werden können. Ein immer noch sehr anschauliches Beispiel ist die Veröffentlichung des Fingerabdrucks von Wolfgang Schäuble im Jahr 2008 durch den CCC [1]. Ein ganz anderes und aktuelles Beispiel für Fallstricke im Zusammenhang mit der Identifikation biometrischer Merkmale liefert die Entsperrung des Handys per Gesichtsscan: Wo als Corona-Schutzmaßnahme Maskenpflicht herrscht, funktioniert die Gesichtserkennung nicht.

Die dritte fundamentale Authentifizierungsmethode basiert auf Wissen. Dies ist in der realen Welt zum Beispiel die PIN, die man an einem Codeschloss oder einem Geldautomaten eingeben muss. Online sind wir damit schon beim Thema “Passwort” angelangt. Ein Unterschied fällt dabei sofort auf: Bei der PIN für die Geldkarte reichen 4 Ziffern, während für einen Onlinedienst deutlich komplexere Passwörter erforderlich sind. Ein gutes Passwort, das nicht zu leicht zu erraten ist, sollte möglichst lang sein, sich aus verschiedenen Zeichenarten zusammensetzen und kein Wort aus einem Wörterbuch sein. Mindestens ebenso wichtig ist, dass das Passwort einzigartig ist und nicht für mehrere Dienste verwendet wird. Sollte ein Passwort doch einmal abhanden kommen, wird der Schaden umso größer, für je mehr Dienste es verwendet wird.

Bei Analogien zwischen realer und digitaler Welt wird das Passwort (zu wissen) meist mit einem Schlüssel gleichgesetzt. Wissen hat in diesem Kontext jedoch den Nachteil, dass es sich weitestgehend verlustfrei kopieren lässt. Das bedeutet: Wenn ein Passwort “abhanden kommt”, dann besitze ich das Passwort selbst weiterhin - und zusätzlich jemand anderes. Unter Umständen bemerkt man also gar nicht, dass das Passwort “abhanden gekommen ist”, denn es ist ja gar nicht weg. Ein Passwortdiebstahl entspricht somit eher einer Schlüsselkopie in der realen Welt. Das Original ist weiterhin im Besitz des rechtmäßig Nutzers, während der Angreifer nun über sein eigenes Duplikat verfügt.

Dass ein Passwort irgendwann einmal kompromittiert wird, ist trotz aller Vorsicht durchaus wahrscheinlich. Eine lange Liste von Leaks zeigt, dass bereits viele große Plattformen wie Facebook oder MySpace betroffen waren und beinahe täglich kommen neue dazu. Werden solche Leaks bekannt und Betreibern von Angeboten wie Have I been Pwned [2] oder dem Identity Leak Checker [3] zugespielt, lässt sich zumindest prüfen, ob man selbst betroffen ist. Wer in einem solchen Fall keine Passwörter mehrfach verwendet hat, muss wenigstens nur das Passwort eines Dienstes ändern und sich keine Sorgen machen, dass zwischenzeitlich weitere Konten mit demselben Passwort kompromittiert worden sind.

Ebenfalls hilfreich in einem solchen Fall ist die Verwendung eines zweiten Authentifizierungsfaktors. Selbst wenn das Passwort bekannt ist, kann der zweite Faktor einen Angreifer an einer Anmeldung am betroffenen Dienst hindern. Das sollte natürlich kein Grund sein, als ersten Faktor dann doch überall das gleiche Passwort zu verwenden.

Mehr­faktor­authen­ti­fi­zie­rung

Bei der Mehrfaktorauthentifizierung werden - zumeist unterschiedliche - Authentifizierungsmethoden der Kategorien

• Wissen
• Besitz
• Inhärenz

kombiniert angewendet. Bei der klassischen Definition von Mehrfaktorauthentifizierung müssen sich die Methoden sogar unterscheiden, zwei verschiedene Dinge zu wissen, ist nach dieser Definition also keine Mehrfaktorauthentifizierung. Im Folgenden wird das aus praktischen Gründen jedoch nicht ganz so streng gesehen - dazu später mehr.

Die Übergänge sind manchmal fließend, so kann das Beispiel der Geldkarte mit PIN-Eingabe durchaus auch als Beispiel für Mehrfaktorauthentifizierung herhalten: Für einen Bezahlvorgang sind Besitz der Karte und Wissen der PIN erforderlich. Das ist - neben der Tatsache, dass nach drei Fehlversuchen die Karte eingezogen wird - auch der Grund, warum ein vergleichsweise schwaches Passwort aus lediglich vier Ziffern für so etwas Sensibles wie einen Bezahlvorgang ausreicht. Gleiches gilt für ein Türschloss, das per Zugangskarte und Code gesichert ist. In jedem Fall wird die Authentifizierung dadurch sicherer, dass ein Angreifer gleich zwei Methoden erfolgreich umgehen muss.

Bei anderen Varianten der Mehrfaktorauthentifizierung werden verschiedene Formen von Wissen miteinander kombiniert: Erstens das eher statische Passwort und als zweiten Faktor ein Einmalpasswort (One-Time-Password, OTP), das für genau eine Anmeldung verwendbar ist und zusätzlich zum normalen Passwort abgefragt wird. An dieser Stelle darf man die obige Definition der Mehrfaktorauthentifizierung also nicht mehr ganz so streng sehen, damit das Modell noch funktioniert. Wichtig in diesem Kontext ist, dass es sich um verschiedene Formen von Wissen handelt, die ein Angreifer typischerweise nicht mit demselben Angriff erlangen könnte. “Alter” und “Wohnort” wären also keine verschiedenen Formen von Wissen, weil beides statische Informationen sind und somit auch in der weniger strengen Betrachtung keine Mehrfaktorauthentifizierung. Mindestens eine der für die Authentifizierung benutzten Informationen muss dynamisch sein und auf einem separaten Kanal übertragen werden.

Bei den Einmalpasswörtern gibt es wiederum verschiedene Varianten. Eine der bekanntesten ist die TAN-Liste aus dem Onlinebanking. Dabei wird einmalig auf einem sicheren Kanal eine Liste von TANs bzw. Einmalpasswörtern ausgetauscht. Listen mit Einmalpasswörtern - egal ob auf Papier oder einem anderen Medium - haben in der Handhabung allerdings mehrere Nachteile: Man muss die Liste dabei haben, um sich anmelden zu können. Man kann die Liste verlieren oder sie kann in falsche Hände geraten. Wenn die Passwörter aufgebraucht sind, muss erneut eine Liste auf sicherem Weg ausgetauscht werden. Zumindest der letzte Nachteil - die notwendige Übertragung - kann durch geeignete Methoden sehr komfortabel gemacht werden: War bei der TAN-Liste noch der Postversand die Regel, wurden im Bankingbereich TANs zunächst per SMS und später Smartphone-App übertragen. In anderen Bereichen wird auch gerne die E-Mail als Übertragungskanal verwendet. Vorteil solcher kurzfristig verfügbarer Kommunikationskanäle: Es muss keine komplette Liste für die spätere Verwendung übertragen werden, sondern es genügt genau ein Einmalpasswort (TAN) für genau die angefragte Aktion. Durch die Bindung des Passworts an die Aktion sind selbst eigentlich nicht sonderlich vertrauliche Kanäle wie E-Mail oder SMS in der Praxis als zweiter Kommunikationskanal durchaus nützlich. Immerhin muss ein Angreifer beide unabhängigen Kommunikationswege zur richtigen Zeit kompromittieren, um Erfolg zu haben. Als Faustregel gilt: Je kürzer das Zeitfenster der Gültigkeit, desto weniger sicher muss der verwendete Übertragungskanal sein.

Die nächste Variante der Einmalpasswörter kommt nach der Initialisierung ohne zusätzliche Kommunikation aus. Beide Parteien berechnen nach einem festgelegten Schema unabhängig voneinander das jeweils gültige Einmalpasswort. Als Basis dienen dabei meistens kryptographisch sichere Hashfunktionen und ein gemeinsames Geheimnis, das beiden Parteien bekannt sein muss und bei der Initialisierung des Verfahrens ausgetauscht wird. Damit sich die generierten Einmalpasswörter auch ändern, geht in die Berechnung noch ein veränderlicher Faktor mit ein. Die gängigsten Methoden verwenden die aktuelle Uhrzeit (Timed One-Time-Password, TOTP) oder einen Zähler (HMAC-based OTP, HOTP) als veränderlichen Faktor.

Bedienkomfort aus Anwendersicht

Alle oben beschriebenen Verfahren erhöhen die Sicherheit bei der Authentifizierung deutlich, allerdings nur, wenn diese auch genutzt werden. Für eine gute Akzeptanz sollte die Bedienung möglichst komfortabel sein. Je nach Rahmenbedingungen wiegen die verschiedenen Vor- und Nachteile dabei unterschiedlich schwer. E-Mail-basierte Verfahren haben den großen Vorteil, dass anwenderseitig keine zusätzliche Infrastruktur erforderlich ist: E-Mail verwendet heutzutage jeder und hat von fast überall auch darauf Zugriff. Der größte Nachteil ist, dass sich diese Verfahren nicht zur Absicherung des E-Mail-Kontos eignen. SMS ist inzwischen zwar beinahe ausgestorben, ist aber weiterhin sehr komfortabel: Für den Empfang wird lediglich ein Mobiltelefon benötigt, was heutzutage fast jeder immer dabei hat. In der Regel ist also auch keine zusätzliche Hardware erforderlich. Für den privaten Einsatz ist das Verfahren damit immer noch sehr gut, beim dienstlichen Einsatz können sich einige Fallstricke ergeben: Entweder Mobiltelefon und zugehöriger Vertrag werden gestellt, wodurch die Kosten für die Dienststelle weniger attraktiv werden. Oder es werden die privaten Geräte und Telefonnummern eingesetzt, was einerseits dienstrechtlich problematisch ist und andererseits nicht jeder Mitarbeiter begrüßen würde. Ähnlich verhält es sich mit Apps, die auf dem Smartphone laufen: Wird die Hardware gestellt, relativiert sich der Kostenvorteil; sollen Privatgeräte der Beschäftigten eingesetzt werden, können die erforderlichen Regelungen schnell kompliziert werden. Für den Privateinsatz oder als freiwilliges Angebot für Studierende sind App-basierte zweite Faktoren hinsichtlich Komfort aber kaum zu schlagen. Unabhängig vom Smartphone lässt sich separate Hardware nutzen. Diese Tokens gibt es in den verschiedensten Varianten: Als separates Gerät mit Display zur Erzeugung und Darstellung von OTPs, als USB-Sticks oder Smartcards. Gerade in letzterem Fall ist die erforderliche Hardware in Form von Mitarbeiter- oder Studierendenausweisen eventuell bereits vorhanden und wird ohnehin mitgeführt. Kritisch ist hier eher die Schnittstelle: An Computern ist USB praktisch immer vorhanden, eine Funkanbindung ans Smartphone per NFC oder Bluetooth ebenfalls meist kein Problem. Schwieriger ist das kontaktbehaftete Auslesen von Smartcards, weil entsprechende Lesegeräte standardmäßig kaum verbaut sind. Biometrische Verfahren sind aus Anwendersicht sehr komfortabel: Auf das Smartphone blicken oder den Finger zum Entsperren aufzulegen geht schnell und funktioniert inzwischen auch sehr zuverlässig. Zudem schützt es davor, dass ein über die Schulter sehender Angreifer die PIN-Eingabe mitliest.

In diesem Blog wird es später einen separaten Artikel von Jens Roesen geben, der genauer auf die Vor- und Nachteile der verschiedenen Verfahren eingehen wird.

Eine zentrale Lösung für die Mehrfaktorauthentifizierung sollte möglichst viele verschiedene Verfahren als zusätzliche Faktoren unterstützen, um die je nach Rahmenbedingungen beste Wahl treffen zu können und nicht schon von Beginn in der Auswahl der Authentifizierungsverfahren eingeschränkt zu sein.

Implementierung und Anbindung an vorhandene Dienste

Die unterstützten Verfahren als zweite Faktoren und deren tatsächliche Anwendbarkeit in der Praxis stellen die eine Seite der Hauptanforderungen dar. Auf der anderen Seite steht eine Schnittstelle, mit der diese Verfahren an die bestehenden Dienste angebunden werden und tatsächlich zur Authentifizierung genutzt werden können. Häufig anzutreffen sind:

• Windows-Anmeldung
• Linux-Anmeldung / PAM
• Identity-Provider / Shibboleth
• E-Mail-Dienst
• Sonstige Webdienste

In der Praxis haben sich dabei einerseits diverse kommerzielle Anbieter herauskristallisiert, die eine All-in-One-Lösung für die Mehrfaktorauthentifizierung anbieten: Token und Backend, letzteres oft als Cloud-Lösung, stammen aus einer Hand. Anwenderseitig werden meist Hardwaretokens, Apps und Login per Website angeboten. Als lokale Aufgaben fallen - vor allem im Zuge der Ersteinrichtung - die Anbindung an die bestehenden Authentifizierungsverfahren der Dienste sowie - als Daueraufgabe - die Verwaltung der Tokens an. Die Tokenverwaltung ist bei kommerziellen Lösungen oft eingebaut, was praktisch sein kann, wenn man wirklich alle Funktionen nutzt. Eine Anbindung an bestehende Infrastruktur kann dagegen komplizierter werden, weil nicht alle Funktionen der gekauften Lösung so wie vom Hersteller vorgesehen verwendet werden. Beispiel dafür ist die Einbindung in eine bestehende Benutzerverwaltung oder die Tokenverwaltung über ein Serviceportal, wie es an vielen Hochschulen bereits implementiert ist.

Andererseits gibt es auch lokale Lösungen, viele davon sogar quelloffen. Auf den ersten Blick können diese arbeitsintensiver als die Lösungen kommerzieller Anbieter erscheinen, man sollte aber berücksichtigen, dass Werbeprospekte die Implementierung oft einfacher aussehen lassen, als sie in der Praxis ist. Eine communitygepflegte Installationsanleitung legt dagegen recht schonungslos offen, was man alles selbst tun muss. Der Lohn dafür ist eine realistische Einschätzung des Aufwands bereits in einem frühen Stadium. Spätere Änderungen fallen außerdem eher leicht, weil man das System bereits bei der Einrichtung sehr gut kennenlernen und verstehen musste und im Backend erforderliche Anpassungen lassen sich bei quelloffener Software selbst vornehmen.

Für bekanntere quelloffene Projekte besteht auch die Option, (kostenpflichtigen) Support in verschiedenen Ausprägungen hinzuzuziehen und so die Einstiegshürde zu verringern. Diverse Anbieter haben sich darauf spezialisiert, die Installation zu begleiten oder auch dauerhafte Unterstützung im Betrieb zu geben. Ebenso lassen sich alternativ zur Eigenentwicklung gewünschte Features auch von kommerziellen Programmierern als Auftragsarbeit in die Projekte implementieren. So kommen nützliche Funktionen einerseits der Community zugute und werden andererseits von dieser oft übernommen und weitergepflegt, so dass die Software nachhaltig verbessert wird.

Passwort­authen­ti­fi­zie­rung verbessern

Auch die reine Passwortauthentifizierung lässt sich mit einfachen Maßnahmen deutlich sicherer betreiben. Wesentlich dafür sind die Generierung und Verwaltung der verwendeten Passwörter. Ein gutes Passwort (siehe oben) ist wegen der Länge und Zufälligkeit nur schwer merkbar. Mit diversen Webdiensten, Accounts für Rechner und E-Mail und vielen weiteren kommt schnell eine hohe zweistellige Anzahl von Passwörtern zusammen, die man sich merken müsste. Dazu kommen je nach Anbieter verschiedene Anforderungen, welche Arten Sonderzeichen das Passwort enthalten darf (muss), wie lang es sein soll und wenn man ganz viel Pech hat, auch noch die Pflicht, das Passwort alle 4 Wochen zu ändern. Während letztere Maßnahme schon immer umstritten war und inzwischen statt einer regelmäßigen Änderung eine anlassbezogene Änderung empfohlen wird, ist das Verweigern trivialer Passwörter oder solcher, die bereits in Datenleaks aufgetaucht sind, eine sinnvolle Maßnahme.

Neben diesen Anforderungen an die Passwortqualität sollten Dienstebetreiber auch serverseitig technische Maßnahmen ergreifen, um die Passwörter ihrer Nutzer zu schützen. Bei einem Angriff auf die Onlineschnittstelle bleibt dem Angreifer in der Regel nur Brute Force, also das Durchprobieren aller Passwörter. Dies kann durch eine Begrenzung der Rate der Authentifizierungsversuche derart verlangsamt werden, dass der Angriff bereits bei halbwegs sicheren Passwörtern nicht mehr effektiv ist. Auch das komplette Sperren der Authentifizierung nach zu vielen Fehlversuchen funktioniert, bietet auf der anderen Seite aber ein unschönes Potential für DOS-Angriffe. Gerade wenn die Benutzernamen bekannt oder leicht zu erraten sind, sollte man sehr genau abwägen, ob einzelne IP-Adressen, Netze oder gleich global die Kennung gesperrt wird. Eine dreimalige Fehlanmeldung bei nicht ganz gedächtnissicherem Passwort oder einem hartnäckigen Mailclient nach einer Passwortänderung kann schnell passieren. Ebenso wie experimentierfreudige Studenten, die mit einem Laptop im Campusnetz innerhalb weniger Minuten die halbe Belegschaft “durchprobieren” können. An gültige Passwörter kommt man so zwar nicht, aber an umso mehr verärgerte Nutzer mit gesperrten Accounts.

Kritischer als ein Angriff auf die Onlineschnittstelle ist ein kompromittierter Authentifizierungsserver, der einem Angreifer Zugriff auf die Passwortdatenbank verschafft. Auch wenn dort nur Hashes gespeichert sind, versprechen Ausprobierraten von vielen Milliarden Versuchen in der Sekunde verhältnismäßig schnelle Bruteforce-Erfolge. In so einem Fall müssen alle im Einsatz befindlichen Passwörter als kompromittiert gelten und davon ausgegangen werden, dass diese früher oder später in einem Leak veröffentlicht werden. Die einzige Möglichkeit als Diensteanbieter ist es, einen Hashalgorithmus zu verwenden, der den Angriff wenigstens so weit verlangsamt, dass alle Nutzer ihre Kennwörter ändern können. Zumindest, wenn man als Betreiber den Angriff erkannt und die Nutzer unmittelbar informiert hat. Moderne Hash-Methoden wie SCrypt oder Argon2 [5, 6] sind darauf optimiert, in der Berechnung aufwändig zu sein und dadurch Angriffe zu verlangsamen.

Wirklich zufällige, individuelle Passwörter sind in der Anzahl für Normalsterbliche kaum noch zu merken. Wer sich diese ohne technische Hilfen dennoch merken möchte, muss Abstriche bei Zufälligkeit oder Individualität des Passworts machen. Das verringert zwar die Sicherheit (zumindest rechnerisch), ist bei sorgfältiger Umsetzung aber ein brauchbarer Kompromiss zwischen Sicherheit und Anwendbarkeit.

Kommen wir zunächst zu den Abstrichen bei der Zufälligkeit: Das menschliche Gehirn ist überhaupt nicht gut darin, sich zufällige Zeichenketten auszudenken. Um dennoch an eine (pseudo)zufällige Zeichenkette zu kommen, die man sich auch noch merken kann, gibt es diverse Tricks und Verfahren. Die bekannteste und aktuell praktikabelste Methode ist der Passwortsatz [7]: Von einem möglichst zufälligen Satz werden die Anfangsbuchstaben sowie einige Sonderzeichen herausgenommen und als Passwort verwendet. Das Ergebnis ist ein weitgehend zufälliges und halbwegs merkbares Passwort: Draußen scheint seit 15 Uhr die Sonne, darum schreibe ich den letzten Absatz auf dem Balkon. Dss15UdS,dsidlAadB.

Mit steigender Anzahl von Passwörtern kommt das Verfahren allerdings an seine Grenzen. Um einerseits nicht das gleiche Passwort für alle Dienste verwenden zu müssen und so die Sicherheit massiv herabzusetzen und andererseits nicht vor dem Problem zu stehen, sich für jeden Dienst einen individuellen Passwortsatz ausdenken und merken zu müssen, bietet sich wiederum ein Kompromiss an: Das finale Passwort wird aus einem gemeinsamen, möglichst zufälligen Teil und einem dienstespezifischen Teil zusammengesetzt. Idealerweise so, dass das Ergebnis keinen Rückschluss darüber erlaubt, welche der gemeinsame Teil ist und nach welchem Schema der dienstespezifische Teil generiert wird. Denn sonst könnte ein Angreifer aus dem kompromittierten Passwort eines Accounts die Passwörter für weitere Accounts ableiten, was nur wenig besser wäre, als das gleiche Passwort für alle Dienste zu verwenden. Relativ gut zu merken, aber schwer zu erkennen, ist es die ersten 2 Buchstabenpaare des Dienstes geschickt auf das gemeinsame Passwort zu verteilen. Für den educv-Blog könnte das zum Beispiel so aussehen edDss15UdS,ucdsidlAadB. Für einen Dienst namens E-Mail so: E-Dss15UdS,MadsidlAadB.

Eine weitere Methode zur Generierung von Passwörtern sind Passwortkarten [8] in ihren verschiedensten Ausprägungen: Auf der Passwortkarte wird einmalig ein Feld mit Zeichen zufällig initialisiert. Die verschiedenen Passwörter werden durch das “Ablaufen” von Pfaden auf dem Zeichenfeld generiert. So muss man sich nur noch den Pfad merken. Inwieweit die Pfade leichter merkbar sind, als das Passwort selbst, hängt vermutlich vom persönlichen Stil ab, sich Informationen zu merken. Angesichts der Tatsache, dass man die Karte auch immer dabei haben muss, wenn man ein Passwort eingeben will, ist diese Methode wohl eher eine witzige Awarenessmaßnahme, um auf Passwortsicherheit aufmerksam zu machen.

Eine weitere Komplikation manuellen Passwort-Merkens und -Eingebens: Viele Dienste werden von mehr als einem Gerät aus genutzt. Angenommen, man kann sich alle Passwörter merken, wird spätestens die wiederholte Eingabe diverser Sonderzeichen des 20-stelligen Passworts auf der Touch-Tastatur eines Smartphones irgendwann lästig. Hier bietet sich ein Passwortmanager an: Dieser speichert die Passwörter sicher verschlüsselt in einer Datenbank, so dass man sich nur noch das Masterpasswort des Passwortmanagers merken muss. Angesichts der Brisanz der damit geschützten Daten sollte dieses wirklich sicher sein und eher ein paar Zeichen mehr als weniger haben. Bewährt haben sich bei den Passwortmanagern solche, die für die Speicherung das Datenbankformat von KeePass [9] verwenden oder KeePass selbst. Falls man sich doch umentscheidet oder auf einer exotischen Plattform keine Implementierung des Lieblingspasswortmanagers bekommen kann, lässt sich zumindest die Datenbank weiterverwenden. Und wer ohnehin einen Passwortmanager verwendet, kann diesen auch zum Generieren sicherer Passwörter verwenden. Eine interessante Entscheidung steht bei der geräteübergreifenden Nutzung an: Nach aktuellem Stand der Technik ist die Datenbank - zumindest bei sicherem Masterpasswort - so sicher verschlüsselt, dass man diese durchaus über Cloudspeicher synchronisieren kann. Wer dem nicht traut, kann die Passwortdatenbank auch rein lokal übertragen, was zwar einen Komfortverlust bedeutet, aber immer noch praktikabel ist. In jedem Fall bietet ein dedizierter Passwortmanager bei vertretbarem Aufwand einen hohen Sicherheits- und nach der Einrichtung sogar Komfortgewinn.

Wer nicht ganz so weit gehen möchte: Auch die Passwortdatenbanken im Browser sind inzwischen - wieder ein sicheres Masterpasswort vorausgesetzt - durchaus praktikabel. Ein Abspeichern ohne Masterpasswort dagegen ist lediglich eine Einladung an Schadsoftware, die Passwörter auszulesen. Da auch Browser das Generieren sicherer Passwörter ermöglichen, ist dies eine Variante, ohne spürbare Einstiegshürde mit der Passwortverwaltung per Passwortmanager zu beginnen. Mit Lockwise [10] können cloud-affine Nutzer dann auch die Synchronisation auf das Smartphone anstoßen. Als praktischer Nebeneffekt warnen Passwortmanager, falls gespeicherte Informationen in einem bekannten Datenleck aufgetaucht sind. So informiert, lassen sich unsicher gewordene Passwörter schnell ändern. Die Funktionalität ist in den meisten Fällen ähnlich, auch die Bordwerkzeuge von Smartphones bieten vergleichbare Funktionen wie Warnungen bei Datenlecks oder Mehrfachverwendung. Ein Feature, das ebenfalls der ein oder andere Passwortmanager bietet, aber nicht genutzt werden sollte, ist die Nutzung als Token für OTP. Denn auf diese Weise werden die beiden eigentlich getrennten Faktoren an einer Stelle vereint, die als einzelne Komponente angegriffen werden kann.

Ein letztes Wort zum Abspeichern: Früher war es verpönt, Passwörter aufzuschreiben und das Post-It am Monitor der Inbegriff der Informationssicherheitssünde. Heutzutage passieren die meisten Angriffe auf Passwörter online, so dass ein sorgfältig im Tresor verschlossener Zettel mit dem Passwort ein vertretbares Risiko darstellt und im Ernstfall des Vergessens oder Nachlasses sehr hilfreich sein kann. Zumindest das Passwort vom Passwortmanager.

[1] https://www.ccc.de/updates/2008/schaubles-finger?language=de
[2] https://haveibeenpwned.com/
[3] https://sec.hpi.de/ilc/search?lang=de
[4] https://v1.escapistmagazine.com/news/view/108247-Gabe-Newell-Gives-Away-Personal-Steam-Password
[5] https://medium.com/analytics-vidhya/password-hashing-pbkdf2-scrypt-bcrypt-and-argon2-e25aaf41598e
[6] https://de.wikipedia.org/wiki/Password_Hashing_Competition
[7] https://www.mach-dein-passwort-stark.de/
[8] https://www.sicher-im-netz.de/dsin-passwortkarte
[9] https://keepass.info/
[10] https://www.mozilla.org/de/firefox/lockwise/

Marius Mertens, ZIM-CERT, Universität Duisburg-Essen