Eingangs ein paar seichte Witze über die Cloud. Wie Sie hiesigen Medienberichten [1, 2, 3, 4] unter Umständen entnommen haben, bekamen LastPass-BenutzerInnen für ihr Vertrauen heuer ein Weihnachtsgeschenk der unerfreulichen Art.

Was ist passiert?

Am 22. Dezember veröffentlichte LastPass das nun dritte Update zu einem Security-Advisory, der zugehörige Incident begann irgendwann Anfang August in einer Entwicklungsumgebung.

Damals wurden mithilfe eines kompromittierten Entwicklerkontos sowohl Quellcode als auch interne Infrastrukturdetails entwendet. Dieser Vorfall ist natürlich unangenehm, jedoch relativ gut eingrenzbar (meinte LastPass am 25. August):

While our investigation is ongoing, we have achieved a state of containment, implemented additional enhanced security measures, and see no further evidence of unauthorized activity.

Rund 4 Monate später dürfte die Situation etwas eskaliert sein, LastPass schreibt nun, dass neben grundlegenden Benutzerdaten wie Name, Rechnungsadresse, E-Mail auch noch weitaus sensiblere Daten gestohlen wurden:

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.

Ein proprietäres Format, welches unverschlüsselte Felder enthält und durch Backups zu einem Drittanbieter hochgeladen wurde - viel kann da ohnehin nicht mehr falsch gelaufen sein.

Glaubt man dem Twitter-Thread eines ehemaligen LastPass-Mitarbeiters lief dort zumindest in der Vergangenheit einiges nicht ideal. Es gab Ambitionen, Verbesserungen zu erzielen - die Umsetzung ebendieser gestaltete sich jedoch vor allem bei langjährigen Nutzern schwierig.

Lots of vault entries may be encrypted with ECB mode AES-256. [4]

Das ist schlecht. Sehr schlecht. Denn dadurch kann auch ohne Entschlüsselung eine Wiederbenutzung von Passwörtern innerhalb eines Vaults erkannt werden. Die technischen Details erspare ich den LeserInnen an dieser Stelle (hier, und hier).

If you had a legacy 5000 rounds or 10000 rounds, the # of rounds can't just be increased server side. [5]

Das National Institute of Standards and Technology (NIST) hat im Juni 2017 in ihren "Digital Identity Guidelines" bezüglich der Rundenanzahl "so viel möglich" empfohlen, aber die Empfehlung mit "typischer mindestens 10.000" beendet.

Dass das URL-Feld im eigenen Vault nicht verschlüsselt wird, dürfte bereits länger bekannt sein - das ist also kaum erwähnenswert.

Was jedoch erwähnenswert ist: 

Warum ich keine Cloud-basierten Passwort-Manager nutze

Grundsätzlich gibt es verschiedene Gründe, warum ich manche Leute die Nutzung eines Cloud-basierten Passwort-Managers ablehnen. Die Gründe dafür sind einfach:

• Sicherheit: Ich möchte meine Passwörter nicht online speichern. Zugegeben: Mein Heimnetzwerk ist wohl ähnlich schlecht abgesichert wie das einiger Cloud-Anbieter - aber es ist meines!
• Privatsphäre: Dadurch, dass mein Vault nicht online ist, sind meine unverschlüsselten URL-Felder vor fremden Augen geschützt. Und da geht es noch gar nicht um die Möglichkeit der Auswertung oder des Verkaufs meiner Daten.
• Abhängigkeit: Einerseits von der Verfügbarkeit des Anbieters, andererseits vom "Internet".
• Kontrolle: Mit einem Offline-Passwortmanager habe ich vollständige Kontrolle über meine Passwortdatenbank. Die Datenbank landet lediglich auf meinen Geräten und ich muss mich diesbezüglich nicht auf einen Drittanbieter verlassen.

Disclaimer:

• Es ist wichtig zu beachten, dass sowohl offlinebasierte als auch cloudbasierte Passwortmanager ihre eigenen Vor- und Nachteile haben. Welche Art für Ihre Bedürfnisse am besten geeignet ist, müssen Sie selbst entscheiden.
• Ich benutze KeePassXC, eine Implementierung des quell-offenen KeePass-Frameworks (sollte ich im neuen Jahr Zeit finden werde ich mir KeeWeb in Kombination mit Caddy und Client-Certificate-Authentication anschauen).