Martins key.matiq-Blog

>> Zurück zum Artikelverzeichnis >>

Sicherheitsbresche bei LastPass

Geschrieben: 10.01.2023
Letzte Überarbeitung: 31.01.2024
Stichwörter: Angriffe, Sicherheit

Der Einbruch bei LastPass wirft Fragen auf: Wäre es nicht sicherer nur Offline-Passwortmanager zu verwenden? Sollten URLs nicht ebenso verschlüsselt werden wie Passworte? Kann sich das LastPass-Desaster nicht jeden Tag auch bei einem anderen Produkt wiederholen?

Der Dateneinbruch ...

... erregt die Gemüter1 zurecht: Es ist nicht der erste Einbruch bei LastPass2, die Firma gab die Informationen über den erfolgten Angriff nur scheibchenweise heraus, und versuchte das Desaster zu beschönigen. Darüber hinaus hatte LastPass jahrelang behauptet, eine "Zero-Knowledge"-Architektur zu verwenden. Gemeinhin versteht man darunter, dass der Server keine Kenntnis der Benutzer*innendaten hat, und diese auf dem Rechner der Nutzer*in (dem Client) stark verschlüsselt werden, so dass man beim Server von "Nullwissen" sprechen kann.

Nun kam aber heraus, dass dies eine glatte Lüge war, dass zwar Anmeldenamen und Passwörter in den gestohlenen Daten verschlüsselt sind, aber Begleitdaten wie die URL keineswegs.

Der eifrigen Leser*in dieses Blogs wird auffallen, dass ich durchaus kein Verfechter davon bin, Begleitdaten und Kerngeheimnisse gleichermaßen zu verschlüsseln. Aber wenn man behauptet es zu tun, sollte man es auch machen, sonst belügt man die eigenen Kund*innen. Auf jeden Fall dann sollte man aber auch Begleitdaten gut vor Datendieb*innen schützen.

Und es stellt sich die Frage, ob, wenn LastPass so stark angegriffen wird, dass sich das Unternehmen gar nicht mehr zu erwehren vermag, nicht doch die verbreitete Skepsis gegen Online-Passwortmanager berechtigt ist.

Es gibt also Einiges zu klären. Das erste ist:

Bei allem Ärger: Häme ist nicht angebracht

LastPass hat sicherlich bedeutende Fehler gemacht, aber es ist natürlich auch einer der ältesten und größten Online-Passwortmanager, und wie beim Malefizspiel schießen sich die Angreifer*innen auf solche Player ein. Als Mitbewerber sitzt man aber selbst im Glashaus. Auch wenn man versucht, Panzerglas zu verwenden, ist doch Vorsicht angebracht. Schließlich können wir in der Cybersicherheit Risiken immer nur minimieren, nie aber völlig ausschalten.

Worin liegen denn die Fehler von LastPass?

Die Kommunikationsfehler habe ich bereits oben angesprochen, aber es gab auch technische Fehler:

LastPass hatte Backups der Datentresore der Kund*innen bei einem Drittanbieter in der Cloud gespeichert. Und zwar ohne die Backups vorher zu verschlüsseln. Das war im konkreten Fall wohl der Hauptfehler.

Also das Problem war gar nicht, dass die Datentresore unverschlüsselte Begleitdaten enthielten, sondern es fehlte einfach eine unabhängige Sicherheitsebene, die sämtliche Daten stark verschlüsselt, egal ob diese bereits mit dem Masterpasswort der Kund*in verschlüsselt sind (wie die Anmeldenamen und Einzelpasswörter) oder als Begleitdaten zunächst noch im Klartext vorliegen (wie die URLs).

Für key.matiq habe ich dieses Thema im Artikel "Persönliche Daten schützen" erörtert. Bei uns werden grundsätzlich Benutzer*innen-Daten im laufenden Betrieb auf verschlüsselten Platten oder aber auf einer RAM-Disk gehalten. Backups werden zunächst stark verschlüsselt und erst in dieser Form auf externen Medien bzw. in der Cloud gespeichert. Sie sind damit nicht weniger sicher, als es z. B. die HTTPS-Kommunikation über das Internet ist.

Man sollte auch richtig rechnen

LastPass behauptet, dass bei ausreichend starken Masterpasswörtern (sie setzen dafür 12 Zeichen an) eine Entschlüsselung von Einzeldaten 10 Mio. Jahre dauern dürfte.

Diese Behauptung offenbart eine ziemliche Ahnungslosigkeit bei LastPass: Immerhin sind schon viele Passwörter in wesentlich endlicheren Zeiträumen herausgefunden worden. Meist, weil von Hand einzugebende Passwörter oft so gewählt werden, dass man sie sich auch merken kann. (Und das Masterpasswort eines Passwortmanagers muss man sich merken können.) Wenn man aber bei der Wahl eines merkbaren Kennworts nicht geschickt genug vorgeht, sieht ein Passwort nicht mehr ausreichend zufällig aus, ist weniger stark und leichter zu knacken.

Sollte eine Benutzer*in tatsächlich einen Zufallszahlengenerator verwendet haben, so kann es vielleicht sein, dass die Entschlüsselungszeit mit einem heutigen Rechner 10 Mio. Jahre betrüge. Dennoch könnte dann ein Kennwort bereits in 30 Jahren entschlüsselt sein, einfach indem man 29 Jahre wartet und dann einen 10 Mio. mal so schnellen Rechner bemüht.3

Wenn nun das Masterpasswort nicht pseudozufällig gewählt wurde (d. h. alle möglichen Kombinationen von zwölf Zeichen durchprobiert werden müssen, um es zu knacken), sonder, z. B. auf die Aussprechbarkeit geachtet wurde, dann verkürzt jedes fehlende Bit an Stärke den nötigen Zeitraum von 30 Jahren um 15 Monate. Und damit rückt die Entschlüsselung der Daten durchaus in greifbare Nähe.

Und schließlich wurden ja zusammen mit den verschlüsselten Kerngeheimnissen auch Begleitdaten im Klartext gestohlen. Diese erleichtern den Hacker*innen das Phishing4, so dass ein Masterpasswort auch über diesen Weg weitaus schneller gefunden werden kann.

Bei all diesen Schönrechnereien wundert es mich schließlich auch nicht mehr, dass sich da die Berechnungen von LastPass immer noch um einen weiteren Riesenfaktor von meinen eigenen Abschätzungen unterscheiden.5

Sollten nicht besser Begleitdaten clientseitig verschlüsselt werden?

Wenn man die Begleitdaten für Passwörter der Benutzer*in nur für die normale Anzeige bei Kenntnis des Masterpassworts benötigt, würde ich das tatsächlich so machen, (also Begleitdaten gemeinsam mit den Kerngeheimnissen mit dem Masterpasswort verschlüsseln).

Allerdings sollte man berücksichtigen, dass Kennwörter auch mal verloren gehen können, auch das Masterpasswort für einen Passworttresor. Auch so, dass eine Wiederherstellung des Zugangs auf andere Weise gar nicht mehr möglich ist. Wenn nun alles und jedes nur mit dem Masterpasswort verschlüsselt ist, kann ein Onlinedienst der Benutzer*in nicht mehr helfen.

LastPass hat für solche Fälle nun gar keine Hilfe vorgesehen, sondern erklärt, dass die Benutzer*in dann alle Daten neu einzugeben hätte.

Bei key.matiq machen wir es anders. In diesem Fall kann die Benutzer*in uns kontaktieren, und, wenn Sie uns das rechtmäßige Eigentum an einer Box nachweist6, kann sie ein neues Hauptkennwort setzen. Allerdings hat sie dann eben nur noch den Zugriff auf die Begleitdaten (die Kerngeheimnisse sind ohne das Hauptkennwort verloren7). Aber es hilft schon sehr, die Begleitdaten zu kennen, um damit auch die Kerngeheimnisse zurücksetzen oder restaurieren zu können. Zumindest hat man eine abzuarbeitende Liste der verlorenen Passwörter und weiß die URLs der Shops, die man um das Zurücksetzen oder auch nur das Löschen der Accounts bitten will.

Wir halten das nicht für unwichtig: Einen Account einfach im Internet unbenutzt und vergessen wie ein Geisterschiff herumsegeln zu lassen, bietet die Gefahr, dass dieser irgendwann dort gehackt wird, ohne dass man es auch nur mitzubekommt. Das könnte Folgeangriffe ermöglichen, bis hin zum Identitätsdiebstahl.8

Also: Begleitdaten nicht wie Kerngeheimnisse zu verschlüsseln, kann durchaus sinnvoll sein. Aber: Wenn ein Dienst diese Unterscheidung trifft, sollte er der Benutzer*in auch die darin steckenden Vorteile zukommen lassen und nicht nur die damit einhergehenden Risiken. Anderenfalls wäre es besser, die Passworttresore komplett zu verschlüsseln.9

Wären nicht Offline-Passwortmanager besser geeignet?

Für manche Zwecke kann man diese durchaus verwenden. Z. B. um sich das Hauptkennwort für key.matiq auf dem PC oder dem Smartphone zu speichern.

Aber das Problem ist, dass Geräte verloren gehen können, oder dass man sich gerade auf Reisen befindet das Gerät nicht dabei hat. Ein weiteres Problem ist, dass man der Partner*in im Notfall den Zugang zu den wichtigsten Kennwörtern geben möchte. Und solch ein Notfallkoffer sollte immer aktuell10 sein. Diese Probleme lassen sich nur mit Online-Passwortmanagern wirklich gut lösen.

Bei allen anderen Lösungsansätzen wird es sehr leicht entweder unsicher hinsichtlich des Zugriffs Unbefugter (z. B. bei Passwörtern in Papierform oder auf unverschlüsselten Medien) oder unsicher hinsichtlich des Zugriffs Befugter im Ernstfall (z. B. bei Änderung eines Masterpassworts, die man vergessen hat der befugten Person zu übermitteln). Also sie funktionieren nicht wirklich!

Sind Online-Passwortmanager nicht riskanter?

Wenn man die LastPass-Bresche sieht, könnte man das denken. Nur man vergisst leicht dabei, dass Offlineprogramme auch nicht ohne Risiken sind. Sonst bräuchten wir keine Virenscanner.

Meist werden Server von kompetenteren Leuten gewartet als private PCs. Deshalb ist es prinzipiell schwieriger, Onlinedienste zu hacken als Offline-Programme. Nur: Viele Hacker*innen konzentrieren sich natürlich auf Server, da es dort mehr zu holen gibt.

Wenn ein Onlinedienst jedoch Daten von Haus aus gut verschlüsselt (verschlüsselte Platten verwendet, Backups grundsätzlich und vollständig verschlüsselt) und alle kritischen Daten (bei denen es keine guten Gründe gibt, es anders zu handhaben) zusätzlich auf dem Client mit dem Masterpasswort verschlüsselt, dann dürfte das Risiko jedoch eher geringer ausfallen als bei Offlineprogrammen, die auf einem durchschnittlich gewarteten PC laufen.

Denn ähnlich wie bei Angriffen auf Fisch- und Vogelschwärmen bietet die große Anzahl der Betroffenen bei einem Datenschutzvorfall auch Vorteile: Einige Betroffene werden zuerst etwas merken und dadurch wird der Vorfall schneller aufgedeckt, was anderen helfen kann, z. B. Passwörter zu ändern, um den Schaden zu begrenzen. Im Schnitt trifft ein solcher Vorfall eine Benutzer*in also keineswegs immer so gravierend, wie es das Hacking des eigenen PCs bedeuten würde.11

Daher tendiere ich dazu, die Frage dieses Abschnitts mit "Nein" zu beantworten.

*

Es bleibt noch eine zu Beginn gestellte Frage übrig:

Kann sich das LastPast-Desaster nicht jeden Tag auch bei einem anderen Online-Passwortmanager wiederholen?

Die Antwort lautet: Ja und Nein. Ja, weil wie eingangs gesagt einfach nicht alle Risiken ausgeschlossen werden können. Das nicht zuzugeben, wäre unredlich. Und natürlich versuchen Hacker*innen, auch andere Passwortmanager zu knacken. Also: Ja, die Möglichkeit besteht.

Aber andererseits lassen sich die wichtigsten Fehler von LastPass schon recht leicht vermeiden. Und allein damit dürften sich die Risiken bereits deutlich verringern lassen. Also: Nein, für besonders wahrscheinlich halte ich jetzt eine Häufung solcher Vorfälle auch bei anderen Online-Passwortmanagern nicht.

Es ist eben wichtig, aus jedem Vorfall rasch zu lernen und die eigene Anwendung noch sicherer zu machen. Wir dürfen uns nicht nur auf eine einzige Sicherheitsmaßnahme verlassen, sondern müssen gewahr sein, dass wir dabei auch Fehler machen können. Deshalb ist es gut, weitere redundante Maßnahmen zu ergreifen, die notfalls ein Versagen anderer Sicherungen kompensieren können. Mit dieser Strategie sind wir jedenfalls bei der matiq UG bisher ganz gut gefahren.

 

1) Siehe z. B. "Ist LastPass noch sicher? Experten kritisieren den Passwortmanager", notebookcheck.com, Nicole Dominikowski, 30.12.2022

2) Hinweise zu Marken Drit­ter:
"LastPass" ist eine Marke oder registrierte Marke von LastPass US LP in den U. S. und anderen Ländern.

3) Das Mooresche Gesetz der regelmäßigen Verdoppelung der Rechengeschwindigkeit gilt immer noch. 1997 schaffte der schnellste Supercomputer der Welt ein Teraflop pro Sekunde, 2022 schafft "Frontier" am Oak Ridge National Laboratory 1,1 Exaflops pro Sekunde. (Siehe "Supercomputer 'Jupiter' kommt nach Jülich", tagesschau.de, 15.06.2022.) Das entspricht einer Beschleunigung um den Faktor 1 Mio. in 25 Jahren, also einem durchschnittlichen Verdoppelungszeitraum von je 15 Monaten. (In diese Beschleunigungsrate mag nicht nur das Mooresche Gesetz eingehen, sondern auch das Wirtschaftswachstum, das erlaubt, größere Rechner zu finanzieren. Aber es ist egal, denn letztlich zählt, dass nach 25 Jahren es gelang, einen um eine Million mal so schnellen Computer zu bauen wie zuvor.

Hochgerechnet könnte somit die Rechengeschwindigkeit in 29 Jahren um den Faktor von rund 10 Mio. steigen.

4) Nach den Empfehlungen des NIST müsste ein kryptografischer Schlüssel 128 Bit Stärke haben, um gegen Entschlüsselung sicher zu sein (d. h. über genügend Jahrzehnte einer Entschlüsselung zu widerstehen). Bei einem Kennwort können bei clientseitiger Verschlüsselung allenfalls 15 Bits davon über Schlüsselstreckung gewonnen werden. D. h. wir bräuchten mindestens 113 Bits. Mit zufälligen sichtbaren ASCII-Zeichen aller Art wären dafür (abgerundet) 17 Zeichen erforderlich. Einem 12-Zeichen-langem Kennwort würden mehr als 34 Bits (bzw. ein Faktor von mehr als 10 Mrd.) an nötiger Stärke fehlen. Siehe auch den Blog-Artikel "Die Mathematik der Passwortstärke".

5) Beim Phishing merken glücklicherweise doch viele Internetnutzer*innen rasch, dass sie hereingelegt wurden und wechseln dann sofort das betroffene Kennwort. (Das sofortige Handeln ist nicht ganz so kritisch, wenn eine Zwei-Faktor-Authentisierung die sofortige Anmeldung der Phisher*in mit dem erbeuteten Masterpasswort unterbindet.) Das nützt aber nichts bei LastPass, wenn die Phisher*in bereits die mit dem erbeuteten Passwort verschlüsselten Daten besitzt (oder später noch in Besitz nehmen kann12).
Der rasche Kennwortwechsel würde aber sehr wohl etwas nützen, wenn LastPass nicht die zusätzliche kennwortunabhängige Verschlüsselung versäumt hätte.
Schlimm ist in diesem Zusammenhang aber auch, dass die Benutzer*innen erst Monate nach dem Hacking informiert wurden, also weder schnell reagieren konnten, noch bezüglich Phishing-Angriffen vorgewarnt waren.

6) Auch bei der Beweisführung hilft, dass bei key.matiq die Begleitdaten nicht mit dem Hauptkennwort verschlüsselt sind. Wir können also, wenn die Antragsteller*in uns bereits schon glaubhaft gemacht hat, dass ihr die verlorene Box gehört, mit ihrem Einverständnis die Begleitdaten mit Angaben der Antragsteller*in vergleichen. So können letzte Zweifel ausgeräumt werden.

7) Solte sich die Box-Eigenümer*in später wieder an das Hauptkennwort erinnern, so kann sie dieses eingeben, um die restlichen verlorenen Geheimnisse wiederherzustellen.

8) Siehe dazu den Blog-Artikel "Identitätsdiebstahl".

9) Aber auch bei einer Komplettverschlüsselung müssten die Daten zusätzlich vor der Speicherung mit einem eigenen Schlüssel verschlüsselt werden. Denn über die Qualität eines Masterpassworts kann man als Passwortmanager nicht viel wissen, wenn man es nicht kennt, und der Server sollte das Masterpasswort ja auch nicht kennen.

10) Also sollte bei einem Wechsel des Hauptkennworts der Notfallkoffer in der Box der Partner*in automatisch mit aktualisiert werden.

11) Bei einem Server von einem halbwegs gut gewarteten Online-Dienst kann man z. B. davon ausgehen, dass es hier aktuelle Datensicherungen gibt. Bei einem PC ist das nicht immer selbstverständlich. Wenn hier ein lokaler Offline-Passwortmanager gehackt wurde, und dann vielleicht noch die Daten zerstört wurden, weiß man also nicht unbedingt, für welche Internetkonten jetzt ein Kennwortwechsel unbedingt angeraten ist.
Dieses Szenario wäre dann für die Benutzer*in deutlich katastrophaler als ein Datenabfluss aus einem (einigermaßen verschlüsselten) Online-Passwortmanager.

12) Wir wissen leider nicht, ob bei LastPass bestehende Backupdaten bei einem Masterpasswort-Wechsel auf das neue Passwort umgeschlüsselt werden oder nicht. Gibt es diese Umschlüsselung nicht, werden auch vor dem Einbruch bei LastPass per Phishing erbeutete Masterpasswörter trotz eines schnellen Passwortwechsels noch eine Gefahr darstellen.
Bei key.matiq gibt es z. B. eine solche Umschlüsselung der Backups bei einem Hauptkennwortwechsel aus guten Gründen nicht, einer ist: Die Kund*in kann ja die Backups auch herunterladen und später wieder importieren, bei dieser Konstellation hat also key.matiq gar keinen Zugriff auf alle Backups. Aber wegen der zusätzlichen vom Hauptkennwort unabhängigen Verschlüsselung ist das bei bei key.matiq kein Problem.
Bei LastPass wäre es aber wegen des Fehlens dieser Sicherheitsebene sehr wohl ein Problem.
(Ein weiterer Grund für die fehlende Umschlüsselung von Backups bei key.matiq ist, dass nach einer Usurpation einer Box es möglich sein sollte, der Usurpator*in die Box wieder wegzunehmen und sie der rechtmäßigen Eigentümer*in zu übergeben. Es ist dann wichtig, dass die Backups vor der Usurpation noch existieren und die Eigentümer*in auch darauf voll zugreifen kann, um die Box wieder in den Zustand vor der Usurpation bringen. Das würde vereitelt, wenn die Usurpator*in zuvor über eine Kennwortänderung die vorhandenen Backups umschlüsseln könnte.)

>> Zurück zum Artikelverzeichnis >>