[Netzwelt] Servereinbruch bei Lastpass

Bei der Online-Passwortverwaltung Lastpass wurde in die Server eingebrochen. Dies hat das Unternehmen auf seinem Blog bekannt gegeben. Es gibt Hinweise dass sich Dritte Zugang zu diversen E-Mail-Adressen, den Passworthinweisen sowie den Authentifizierungshashes vieler Nutzer verschaffen konnten. Ein ähnlicher Einbruch fand bereits 2011 statt.

Lastpass versichert, dass die Authentifizierungshashes jeweils mit einem zufälligem Salt versehen und serverseitig 100.000 Iterationen von PBKDF2-SHA256 bearbeitet wurden. Somit seien die Hashes nur mit einem sehr großen Aufwand zu knacken. Das Unternehmen wird dennoch die Nutzer anschreiben und sie auffordern dass sogenannte Masterpasswort zu ändern. Neu hinzugefügte Geräte müssen zudem per E-Mail bestätigt werden. Alternativ ist die Nutzung einer Zwei-Faktor-Authentifizierung möglich.

Quelle: Golem.de

 

[Metal_Warrior]

@virtus:
Nein, ich sage, dass der Umwegsangriff für alle Situationen, in denen nicht direkt von Gehirn nach OTP gearbeitet wird, möglich wird und damit OTP hinfällig. Lies doch!

Das Argument ist ein ganz einfaches: Ein maschinenlesbar gespeicherter Schlüssel ist generell als Sicherheitslücke zu betrachten. Wie du ihn sicherst ist der Knackpunkt an der ganzen Geschichte. Der Nachteil von OTP ist die erforderliche Länge, die einen Key "auffällig" macht. Wie gesagt, ich habe OTP verstanden, ich WEISS,was du mir seit 2 Seiten erzählen willst. Wenn du auch ordentlich lesen würdest wäre dir klar, dass ich niemals OTP direkt angegriffen habe, sondern immer mit Keywahrscheinlichkeiten, deterministischen Funktionen und Prüflogik an die möglichen Keys rangegangen bin. Und ja, man merkt, dass du kein Cryptoexperte bist, weil du die Umgebung nicht betrachtest.

 

[Rakorium-M]

@Rakorium-M: Wie willst du Abhängigkeiten zwischen den Nachrichten feststellen?
Beim Hochladen des Cyphers auf einen Server hast du etwa: 1001010101001010101101010110101010110101
Beim Abrufen hast du jedes mal die gleiche bit-Folge: 1001010101001010101101010110101010110101
Zumindest solange, bis du einen neuen Klartext und ein neues Pad verwendest: 1111011101010101001010101010110101011010101010101010110101010111

Welche Abhängigkeiten siehst du denn da? Solange du nicht (a) das gleiche Pad mit einem neuen (gleich langen!) Klartext verwendest oder (b) den gleichen Klartext mit einem neuen Pad verwendest, gibt es keine Abhängigkeiten.

War etwas ungünstig formuliert. Ich meinte Abhängigkeiten zwischen mehreren Klartexten, die mit dem gleichen Schlüssel (Pad) verschlüsselt wurden. Bei einer einzigen Anwendung pro Key (und korrekter Generierung eines solchen) ist reines OTP natürlich sicher.

Okay, stell dir vor du rufst eine bit-Folge Daten aus einer Datenbank ab, etwa einen String: 1001010101001010101101010110101010110101
Da brauchst du keinen Header, der sich auf die Daten bezieht, trotzdem kannst du die Daten nutzen. Es gibt höchstens einen Header, der sich auf den Container bezieht, welcher die Daten beinhaltet. Das lässt aber in der Regel keine Rückschlüsse auf die Daten selbst zu.

Deine "Prüflogik" kannst du nur anwenden, wenn du Annahmen über die darin enthaltenen Daten anstellen kannst. Du kannst bei einem beliebigen Cypher allerdings keine Annahmen über die enthaltenen Daten machen. Insbesondere nicht, was für Daten vorliegen. Du kannst nicht annehmen, ein Datum enthielte einen bestimmten Header, schlicht weil das nicht für alle Daten nötig ist. Wie gesagt, ein einfacher String als Rückgabe einer Funktion/ eines Datenbank-Querys enhält per se keine Header-Information. Das Argument "ich bruteforce auf 2^n und dann fallen 0 bis 2 eindeutige Ergebnisse heraus, von denen man 1 mit 100%iger Sicherheit ausschließen kann" ist nicht.

Wenn nur rein zufällige Daten verschlüsselt werden sollen, ist das ziemlich einfach. Auf diesem Best-Case eine Sicherheits-Argumentation aufzubauen, ist aber äußerst riskant. Der Cipher sollte ja schon für alle Eingaben sicher sein, nicht nur für komplett zufällige. In der Praxis verschlüsselt man eher selten zufällige Daten, und ein Algorithmus, der nur für solche zufälligen Bitfolgen funktioniert, kann man zurecht als gebrochen bezeichnen. Eine Verschlüsselung muss für alle Eingaben funktionieren, also auch strukturierte Daten, Dateien mit Header, und sogar einem Angreifer teilweise bekannte Texte.
Tatsächlich gilt ein Algorithmus schon als gebrochen, wenn es nur einen einzigen Klartext gibt, dessen Ciphertext geknackt werden kann.

Kurzum: Es liegt nie an OTP. Es liegt immer am Schlüssel, und der ist das Angriffsziel. Das ist und war schon von Anfang an mein Punkt. Es sind die Anforderungen an den Schlüssel, welche den Algorithmus in der Verwendbarkeit auf nahe Null einschränken.

Das ist genau das Kernproblem des OTP. Reines OTP (richtig angewendet) ist sicher, solange der Schlüssel sicher ist. Sobald man am Schlüssel was dreht, sieht das ganze wieder anders aus.

1. Liegt der Schlüssel in einer Datei, und kann diese auch gestohlen werden, ist das System nicht mehr sicher
2. Benutze ich einen weiteren Algorithmus A, um den Schlüssel zu schützen, und benutzt A einen Key dafür, der kürzer als mein OTP-Schlüssel ist, kann Bruteforce angewendet werden. Grund ist, dass dann ein größerer Teil der OTP-Schlüssel ausgeschlossen werden kann (durch A-Decrypt nicht reproduzierbar), und dadurch nicht mehr jeder Klartext möglich wird. Wohlgemerkt, gemessen an der Worst-Case-Situation für Klartexte. Ist genau die selbe Überlegung wie bei OTP+PRG in meinem letzen Beitrag.
3. Wird ein PRG benutzt, um den Schlüssel zu generieren, ist das System durch Bruteforce angreifbar.
4. In Fall 2+3 entscheidet die Verschlüsselung bzw. der PRG, ob der Bruteforce-Angriff mit den gegebenen Ressourcen durchgeführt werden kann.

tl;dr
Verschlüsselung muss auch für nicht zufällige Eingaben funktionieren.
Reines OTP richtig angewendet ist sicher gegen Bruteforce.
Jeder Konstruktion, die darauf abziehlt, sich einen Schlüssel merken zu können, der kürzer als die eigentliche Nachricht ist, ist zwangsläufig bruteforce-bar (beweisbar).


Gruß
Rakorium