Passwortmanager: Von Lastpass zu Bitwarden

TL;DR: In diesem Text geht es um meinen Wechsel des Passwortmanagers, nachdem sich Lastpass als zu unzuverlässig erwiesen hat. Vorangestellt werden ein paar Überlegungen dazu, warum man eigentlich einen Passwortmanager braucht und wie man ihn sicher nutzt. Abschließend geht es um die Frage, wie mit dem Datenverlust bei Lastpass umzugehen ist: Muss ich jetzt alle meine Passworte ändern?

Eine der wesentlichen Regeln der Passwortsicherheit ist die Verwendung von individuellen Logins für jeden Dienst und Zweck. Angesichts immer wiederkehrender Verluste von Logindaten bei erfolgreichen Angriffen auf Webdienste kann man nur so den Schaden auf den jeweiligen Dienst begrenzt halten. Es nutzt nichts ein einzelnes, super sicheres Passwort zu haben, welches man immer verwendet. Denn schon ein erfolgreicher Einbruch bei einem einzigen der Dienste, bei denen man das Passwort verwendet, wird dazu führen, dass die Angreifer danach auch die anderen Dienste mit den so gewonnenen Logindaten erfolgreich angreifen. Diese Art des Angriffs ist so häufig, dass sie einen eigenen Namen bekommen hat: Credential stuffing

Auch 2-Faktor-Authentifizierungen ändern daran erst einmal nicht grundsätzlich etwas, und bis wir überall Passkeys einsetzen und keine Passworte mehr brauchen wird es noch etwas dauern.

Ein Passwortmanager ist unverzichtbar

Zwar kann man so eine Vorgehensweise auch ohne digitale Unterstützung umsetzen, entweder mit einem Notizbuch für die Passworte, oder durch Schemata, bei denen man ein komplexes Grundpasswort nach eigenen Regeln jeweils individualisiert, aber die Verwendung eines Passwortmanagers macht diese Vorgehensweise erst in einer Weise handhabbar, die den digitalen Lebenswandel und Arbeitsalltag nicht so sehr erschwert, dass es nicht mehr praktikabel ist.

Auch bieten die gängigen Passwortmanager einige Vorteile im Vergleich zu manuellen Lösungen:

  • Generierung von Passworten: Es gibt üblicherweise Funktionen, um sich lange und zufällige Passworte mit vielen Zeichenvariationen mit einem Klick zu erzeugen. Zufällig generierte Passworte bieten den höchsten Schutz gegen Passwortrateversuche, selbst wenn Angreifer dabei sehr viel Zeit und sehr viel Rechenleistung zur Verfügung steht
  • Umgang mit sehr langen Passworten: Der Passwortmanager nimmt einem eventuell noch vorhandene Hemmungen sehr lange Passworte zu verwenden. Also Passworte mit Längen jenseits von 30 Zeichen, die man bei einer manuellen Handhabung wohl eher scheut
  • Schutz vor homographischen Angriffen: Wenn der Passwortmanager verwendet wird zum automatischen Ausfüllen von Logins in Webseiten kann man auf diese Art von Angriffen – bei denen sehr ähnliche oder gar völlig identisch aussehende Webadressen verwendet werden – nicht hereinfallen. Bzw. muss dann als Nutzer*in selbst aktiv die Logindaten eingeben und könnte sich bei der Gelegenheit wundern, warum der Passwortmanager das nicht tut

Aber es gibt natürlich auch Nachteile, gerade wenn es um die ganz besonders bequemen Passwortmanager mit einer Synchronisierung über die Cloud geht. Da heute nahezu jede*r mindestens 2 Geräte haben wird, auf denen man sich irgendwo einloggen will, muss man in der Lage sein die Inhalte des Passwortmanagers – nennen wir ihn den ‚Tresor‘ – sicher zwischen diesen Geräte zu transportieren.

Das kann man selbst machen, aber das ist mit einem gewissen Aufwand verbunden und braucht eine hohe Sorgfalt, damit keine Fehler beim Umgang mit diesen kritischen Daten passieren. Es gibt aber inzwischen eine Reihe von Anbietern, die die Passwortmanagerinhalte über die Cloud synchronisieren und dabei vor allem dies versprechen:

Zero Knowledge Architekturen

Mit dem ‚Null Wissen‘ ist dabei gemeint, dass der Anbieter des Passwortmanagers zwar die Inhalte in der Cloud speichert und so zwischen den Geräten synchronisieren kann, aber nicht in der Lage ist die Inhalte selbst zu sehen bzw. zu entschlüsseln. Das ist durch eine entsprechende Programmierung der Passwortmanagersoftware möglich, da die Entschlüsselung letztlich nur auf den Geräten der Nutzer*innen – also lokal und nicht in der Cloud – stattfinden muss.

Auf diese Weise lassen sich zwei Probleme lösen:

  1. Wie viel Vertrauen brauche ich in meinen Passwortmanageranbieter? Je weniger der Anbieter von meinen Daten sehen kann, desto weniger Vertrauen muss ich zu ihm haben. Ganz ohne Vertrauen geht es natürlich nicht: Da meist die Passwortmanagersoftware vom gleichen Anbieter kommt wie die Cloudsoftware, die die Daten synchronisiert, muss ich darauf vertrauen, dass die Software nicht doch mein Passwort direkt in die Cloud schickt. Oder die Inhalte meines Passworttresors im Klartext
  2. Was passiert, wenn meine ganzer Passwortschatz abhanden kommt? Da der Passwortmanager, wenn er richtig genutzt wird, der Schlüssel zum gesamten digitalen Leben ist, kann er in den falschen Händen maximalen Schaden anrichten. Dabei kann er sowohl vom eigenen Gerät entwendet werden, wie auch aus der Infrastruktur des Anbieters. Erfolgreiche Angriffe auf Clouddienste sind keine Seltenheit, dabei trifft es alle Ebenen: Vom grundlegenden Cloudserviceanbieter (Beispiel Rackspace) über die Softwareentwicklungsinfrastruktur (Beispiel Circle CI) bis hin zum IT Sicherheitsdienstleister selbst (Beispiel Okta). Im Idealfall könnte ich meinen verschlüsselten Passworttresor auch frei ins Internet stellen und niemand könnte mit einem vernünftigen Ressourceneinsatz meine Passworte daraus extrahieren, so dass ich mir selbst im Fall eines erfolgreichen Angriffs auf meinen Dienstleister keine (großen) Sorgen machen muss

‚Das letzte Passwort, das Sie jemals brauchen werden‘

Der Schutz des Passworttresors und seiner wichtigen Inhalte hängt nun von einer einzige Sache ab: Dem Passwort, welches man für den Passwortmanager verwendet. Dieses Passwort wird verwendet um den Tresor zu verschlüsseln und dann auch wieder zu ‚öffnen‘. Wer es besitzt hat damit die komplette Kontrolle über alle im Tresor gespeicherten Logindaten.

Im Idealfall ist es dann das ‚letzte‘ Passwort, welches man in dem Sinne braucht, dass man es sich merken und manuell eintragen muss. Produkte wie Lastpass oder 1Password verdanken dieser Idee ihre Namen. Oft wird dieses Passwort als das Masterpasswort bezeichnet

Da man dieses Passwort häufig benötigt um den Tresor zu entsperren ist es praktisch es sich merken zu können und so kann man ausgerechnet beim wichtigsten Passwort von allen kaum auf ein langes, zufällig generiertes Passwort setzen. Sondern muss sich für eine Vorgehensweise entscheiden um ein Passwort zu finden, welches auch in dem Fall, dass der damit verschlüsselte Tresor Angreifern in die Hände fällt, für eine ‚vernünftige‘ Zeit vermutlich nicht knackbar ist.

XKCD 936: Password strength

Die Ratschläge wechseln dabei mit der Zeit, die Vorgehensweise oben im Comic scheint heute immer noch aktuell, nur sind 4 Worte wohl nicht mehr genug. Hier ein paar Links dazu:

  • Tipps vom BSI – Wobei die Aussage, dass ein ‚gutes Passwort‘ mehr als 8 Zeichen haben sollte, für ein Masterpasswort viel zu schwach ist. Hier sollte man schon etwas jenseits von 15 Zeichen haben, besser noch mehr
  • Bitwardens Passwortstärkeprüfung: Diese Seite gibt einem ein Feedback dazu, wie sicher ein Passwort vermutlich ist. Hier kann man ein Gefühl dafür bekommen, wie Länge und verwendete Zeichenarten die Komplexität beeinflussen, und die steht wiederum im direkten Verhältnis zum Aufwand, den potentielle Angreifer zum Erraten betreiben müssen
  • Password Haystack von GRC: Diese etwas nerdige Seite von Steve Gibson (vom Security Now Podcast) kann einem ebenfalls ein Gefühl dafür geben, wie komplex ein Passwort ist und wie sich die Länge und weitere Zeichenklassen (Groß- und Kleinschreibung, Zahlen, …) auf die Anzahl der Passwortkombinationen auswirken, die ein Angreifer durchtesten müsste. Das ist kein völlig korrektes Maß für die sogenannte Entropie eines Passworts und die Zeiten, die dort prognostiziert werden um ein Passwort zu brechen, sind nicht mehr realistisch angesichts heute verfügbarer Hardware. Trotzdem vermittelt es einem ein Bild davon, wie sich Komplexität erzeugen lässt. So ist ein Passwort, in dem man irgendwo zehn ‚.‘ oder ähnliches eingefügt hat und welches dadurch auf eine enorme Länge kommt durchaus für Angreifer, die davon nichts ahnen, sehr schwer zu erraten
  • Have i been pwnd: Hier kann man prüfen, ob ein Passwort schon einmal in gehackten Konten vorkam. So ein Passwort sollte man in keinem Fall mehr verwenden

Generelle Hinweise:

  • Das Masterpasswort sollte keins sein, welches man vorher schon irgendwo verwendet hat. Und man sollte es dann auch für keinen anderen Zweck verwenden
  • Es gibt keinen Grund das Passwort regelmäßig zu ändern, es sei denn man möchte es noch länger / komplexer machen
  • Das Masterpasswort sollte man sich ggf. aufschreiben und an einem sicheren Ort verwahren. Gerade ein kompliziertes Passwort vergisst man nach einem langen Urlaub auch schon mal
  • Man sollte das Masterpasswort nur auf Geräten eintragen, die vertrauenswürdig sind. Vertrauenswürdig ist zum Beispiel sicher nicht ein Internetcafé am Urlaubsort, aber ggf. auch keine Geräte von Bekannten oder Freunden. Es ist für Besitzer*innen fremder Geräte einfach zu leicht eine Tastatureingabe mitzuschneiden und so an das Passwort zu kommen

Das Versagen von Lastpass

Ich habe mich vor Jahren für Lastpass als meinen cloud-basierten Passwortmanager entschieden und eine der kostenpflichtigen Optionen gewählt. Auf dieses Produkt bin ich denke ich durch den Security Now Podcast aufmerksam geworden, der ursprüngliche Entwickler von Lastpass hat sein Produkt damals für Steve Gibson geöffnet und dieser hat einen Review des Konzepts gemacht, welches zu dieser Zeit State of the art war. In den folgenden Jahren wurde Lastpass aufgekauft und der ursprüngliche Entwickler hat das Unternehmen schon lange verlassen. Aber aus Nutzersicht war und ist es ein Produkt, welches seine Aufgabe im Webbrowser und auf Android und iOS problemlos erledigt.

Auf Grund der Zero Knowledge Architektur war dann auch die Meldung von Lastpass Anfang Dezember 2022 (inzwischen aktualisiert) über einen Sicherheitsvorfall, bei dem die verschlüsselten Passworttresore gestohlen wurden, zunächst ärgerlich, aber noch nicht sehr besorgniserregend:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data. 

Quelle Lastpass Blog

Natürlich ist der Verlust der Informationen dazu, welche Webseiten ich nutze, schon ein durchaus heftiges Datenschutzproblem und eine ideale Grundlage für Phishingangriffe. Trotzdem war der Stand zunächst der, dass durch die Art und Weise, wie aus dem Masterpasswort die Verschlüsselung generiert wird, die wirklich wichtigen Daten geschützt sind. Der Blogeintrag bestärkt diesen Eindruck noch:

To further increase the security of your master password, LastPass utilizes a stronger-than-typical implementation of 100,100 iterations of the Password-Based Key Derivation Function (PBKDF2), a password-strengthening algorithm that makes it difficult to guess your master password. You can check the current number of PBKDF2 iterations for your LastPass account here

Quelle Lastpass Blog

Nun kommen aber die Erkenntnisse ins Spiel, die im Verlauf dieser Security Now Episoden stückweise ans Tageslicht kamen:

Das sind für mich insbesondere diese Punkte:

  1. PBKDF2 Iterationen: 5000! Der Schutz meiner von Lastpass gestohlenen Daten hängt nur daran, dass Angreifer mein Masterpasswort nicht knacken. Mein Passwort ist deutlich länger als die von Lastpass zu diesem Zeitpunkt empfohlenen 12 Zeichen. Aber Lastpass selbst kann die Sicherheit sehr einfach durch die Anzahl der Iterationen erhöhen, die beim PBKDF2 Verfahren verwendet werden. Und hier ist es eine schlichte Lüge, dass hier mehr als 100.000 Iterationen verwendet werden. Bei mir waren nur 5.000 eingestellt, da ich ein langjähriger Nutzer bin und offenbar noch die Einstellung habe, die bei meiner ersten Nutzung von Lastpass aktuell war. In der 905er Episode behandelt Steve Fälle, bei denen es gar nur 1 Iteration war! Wieso hat Lastpass uns bisher treue Altnutzer nicht automatisch umgestellt? Als ich das manuell gemacht habe musste ich mich einmal neu einloggen und ein paar Sekunden warten, dann war das erledigt. Das hätte Lastpass in den letzten Jahren einfach mal automatisch tun können
  2. ECB verschlüsselte Passworte: In alten Versionen von Lastpass wurden Passworte nach dem ECB Verfahren verschlüsselt. Auch wenn das eine sichere Verschüsselung ist hat sie den Nachteil, dass die gleiche Eingabe immer das gleiche Ergebnis erzeugt. Es ist also in den verschlüsselten Daten einfach erkennbar, wenn jemand ein Passwort mehrfach verwendet hat. Später hat Lastpass auf das CBC Verfahren umgestellt, welches dieses Problem nicht hat. Es aber auch hier versäumt die Altdaten komplett umzustellen. In dem Lastpass Extrakt, den man sich nach dem in Folge 904 vorgestellten Verfahren herausziehen kann, finde ich zahlreiche ECB-kodierte Passworte
  3. Kein Zwang zu guten Masterpassworten: Das Problem betrifft mich nicht, aber offenbar hat Lastpass nie seine eigene Vorgabe durchgesetzt mindestens 12 Zeichen lange Passworte zu verwenden. Sie haben ihre Nutzer*innen damit in unverantwortlicher Weise sich selbst überlassen
  4. Herunterspielen der Menge an unverschlüsselten Daten: Es scheint, also enthalte der gestohlene Datensatz eine Menge an unverschlüsselten Informationen, die Lastpass für den Betrieb seiner Services nicht benötigt. Diese Daten sind nun direkt für die Angreifer auswertbar und helfen ihnen mindestens bei der Priorisierung welche Passworte sie ggf. zuerst angreifen sollen
  5. Mangelhafte Kommunikation: Insgesamt macht es den Eindruck, dass es Lastpass eher darum geht den Vorfall herunterzuspielen und eventuelle Datenverluste den Kunden in die Schuhe zu schieben. Auch wenn sie es in der Hand gehabt hätten hier viel für die Sicherheit zu tun

Letztlich hat mich die Menge der Probleme und der unprofessionelle Umgang damit dazu veranlasst ähnlich wie Steve Gibson nun Abschied von Lastpass zu nehmen.

Bitwarden als neue Lösung

Trotz der Erfahrung, dass meine Passwortmanagerdaten einmal in der Cloud abhanden gekommen sind, bleibe ich beim Grundprinzip eines cloud-basierten Passwortmanagers. Alles andere ist einfach zu umständlich. Zum Glück gibt es einige Alternativen, die in Episode 904 auch kurz diskutiert werden. Von den da genannten Kandidaten Dashlane, 1Passwort und Bitwarden habe ich mich für letzteren entschieden.

Ein Grund ist, dass es sich hier um eine Open Source Lösung handelt, die aber zugleich ein Serviceangebot hat, welches man kaufen kann. So hat man zwar die Option eines selbstverantwortlichen Betriebs, aber wenn man das nicht kann oder möchte nutzt man den Service in der Cloud.

Kann man sicher sein, dass Bitwarden keine ähnlichen Probleme hat oder bekommt wie Lastpass? Letztlich nicht wirklich, allein das es sich hier um Open Source handelt ist keine Garantie dafür, dass komplexe Algorithmen korrekt implementiert sind, keine sonstigen Fehler in der Software sind und das der Betrieb der Cloudplattform kompetent erfolgt. Aber zumindest könnte man in einem vergleichbaren Fall einfach nachsehen wie die Software funktioniert, und müsste nicht herumraten, wie es bei Lastpass nun der Fall ist.

Die Migration an sich hat bei mir gut funktioniert, man nutzt entsprechend der Anleitung den Export von Lastpass und holt diese Daten dann nach Bitwarden.

Nach dem ersten Eindruck ist die Oberfläche etwas weniger gefällig, als die von Lastpass, aber nicht in einem für mich abschreckenden Maß. Etwas Feintuning kann man dann noch machen und die Anzahl der Iterationen für die Schlüsselableitung (KDF) erhöhen. Sie liegt per Voreinstellung bei 100.000, also auf dem Level, welches Lasspass bei neuen Nutzer*innen setzt. Aber man kann sie hochsetzen, und heutige Smartphones verkraften auch deutlich höhere Werte:

Bitwarden: KDF-Iterationen bearbeiten

Zur Erinnerung: Die Anzahl der Iterationen erhöht direkt den Aufwand, den Angreifer in einem Szenario wie dem Datendiebstahl bei Lastpass erbringen müssen und hier hat man neben der Komplexität des Masterpassworts noch eine weitere Stellschraube. Der Wert von mehr als einer Million scheint auf meinem Geräten keine Schwierigkeiten zu bereiten, auch auf dem alten iPad Mini als wohl leistungsschwächsten Gerät dauert das Öffnen des Tresors nur eine Sekunde.

Ich habe meinen Lastpass Account noch nicht gekündigt und werde noch ein paar Wochen beobachten, wie sich Bitwarden schlägt, aber Passwortänderungen werden nun nur noch über den neuen Passwortmanager gemacht.

Umgang mit den bisher bei Lastpass gespeicherten Passworten

Ich muss davon ausgehen, dass mein kompletter Passworttresor heute in den Händen von Kriminellen ist. Zusammen mit den Tresoren von Millionen von anderen Lastpass Nutzer*innen. Trotz der oben benannten kritischen Punkte bei der Verschlüsselung gehe ich nicht davon aus, dass meine Daten schon geknackt wurden. Aus diesen Gründen:

  1. Ich stelle vermutlich kein speziell interessantes Ziel dar, welches besondere Aufmerksamkeit und umfangreiche Investitionen an Rechenzeit rechtfertigt
  2. Bei einer opportunistischen Vorgehensweise der Angreifer – leichte Ziele vor schweren Zielen angehen – sind die Nutzer*innen, die eine noch kleinere Anzahl von PKDF-Iterationen hatten (vielleicht nur eine einzige!) wohl eher ‚dran‘ als ich. Allerdings gibt es keine vollständige Information darüber, in welchem Maße die schwachen Iterationszahlen vorhanden sind, wann ich nach dieser Logik als ‚dran‘ wäre
  3. Mein Masterpasswort war nicht schwach und erfüllte die oben von mir selbst aufgestellten Massgaben
  4. Ich habe bisher keine ungewöhnlichen Aktivitäten bei meinen diversen Konten bemerkt

Trotzdem…es wäre absurd zu glauben, dass nicht irgendwann die Daten meines Tresors zugänglich werden, sei es in ein paar Wochen, Monaten oder Jahren, die Logindaten müssen also geändert werden. Allerdings habe ich hunderte von Logins in meinem Tresor, es ist daher eine Priorisierung notwendig. Das ist meine Reihenfolge:

Priorität 1: Zentrale Mail- und Betriebssystemkonten

An wichtigsten sind die Google Konten. Nicht nur enthalten sie selbst jede Menge wichtige Daten, sie sind auch bei vielen Services als Adressen eingetragen für Passwortresets. Wer diese Konten kapert, der kann sich dann auch ohne gestohlenen Passworttresor den Zugriff auf viele Konten sichern.

In gewisser Weise gilt das auch für die Konten bei Microsoft und Apple, die den Zugriff auf die Betriebssysteme dieser Anbieter ermöglichen und ebenfalls zentrale Angriffspunkte sind.

Priorität 2: Finanzen und große Einkaufsplattformen

Danach kommen direkt die Konten bei Banken und Onlinefinanzdienstleistern. Ein Zugriff darauf kann unmittelbaren finanziellen Schaden erzeugen, auch wenn hier heute immer ein weiterer Faktor wie eine dynamische TAN benötigt wird. Auch Plattformen wie Amazon gehören für mich dazu, da hier ebenfalls das Potential zu wesentlichen finanziellen Schäden besteht.

Priorität 3: Eigene Webseiten und Social Media

Eine Übernahme meiner digitalen Identität im Netz würde über Jahre aufgebaute Repräsentationen zerstören und hat das Potential auch andere zu schädigen, falls Angreifer versuchen sollten sich auf diese Weise Vertrauen zu erschleichen.

Priorität 4: Der große Rest

Danach bleiben immer noch eine Menge von Konten, für die eine Lösung gefunden werden muss. Bei vielen wird sich eher die Frage stellen ob man sie nicht komplett aufgibt, statt das Passwort zu ändern. Denn jeder Service, der Daten von einem verwaltet, ist letztlich ein potentielles Angriffsziel, über das Daten abfließen können.

ihbrune

1991-1996: Studium der Naturwissenschaftlichen Informatik an der Universität Bielefeld. Abschluss mit der Diplomarbeit zum Thema 'Analyse von ein- und mehrdimensionalen Zeitreihen mit der Karhunen-Loève- und Wavelet Transformation' || 1996-1997: Wissenschaftlicher Mitarbeiter am Lehrstuhl Prof. A. Knoll in der Technischen Fakultät der Universität Bielefeld im Projekt 'LANeCo: Local Area Net Configuration' || 1998- 2018: Tätigkeit im BIS - Bielefelder Informationssystem an der Universität Bielefeld || Seit Oktober 2018: Leitung der Abteilung Informationssysteme und Prozessunterstützung im BITS