Vor kurzem rauschte eine Meldung durch den Online-Blätterwald: Sicherheitslücke beim Online-Speicher Dropbox lauteten beispielsweise die reißerischen Titel.
Ich komme da nicht ganz mit. Unter einer Sicherheitslücke verstehe ich klassischerweise einen Umstand, der es Leuten ermöglicht, ohne Authentifizierung Dinge zu tun, für die sie sich normalerweise anmelden müssten. Genau das ist hier aber nicht der Fall – vielmehr geht es um etwas viel Einfacheres: Es geht um die Erschleichung eines Zugriffs durch den Klau von Authentifizierungsdaten. Das ist, um’s mal vorsichtig zu sagen, ein alter Hut und auch kein Dropbox-spezifisches Problem. Jeder, der auf seinem Rechner irgendwo Passwörter gespeichert hat, sei es im Browser, sei es in einem FTP-Client, unterliegt einer völlig vergleichbaren „Sicherheitslücke“: Wer in jenen Rechner einbricht und diese Daten kopiert, hat damit Zugriff auf die Accounts des betreffenden Users. Gleiches gilt beispielsweise auch für Cookies: Wer einen Cookie stehlen kann, stiehlt damit implizit auch den Zugang, der hypothetisch hinter diesem Cookie steht. Viele Cookies dienen ja dazu, jemanden im Lauf einer Session wiederzuerkennen, ohne dass er sich für jeden Seitenaufruf erneut identifizieren muss – der Cookie ersetzt also die Authentifizierung mit Username und Passwort. Insofern halte ich das für hanebüchen, die „Entdeckung“ als „Sicherheitslücke“ zu bezeichnen.
Im Grunde passen Cookies sogar als noch besserer Vergleich zu Dropbox als abgespeicherte Passwörter. Die Authentifizierung bei Dropbox funktioniert nämlich so, dass man bei Einrichtung des Clients auf einem Rechner seine Dropbox-Zugangsdaten angibt, der Client authentifiziert sich damit und besorgt sich eine sogenannte Host-ID. Diese wird dann abgespeichert und dient dann künftig – anstelle der Zugangsdaten – als Authentifizierung. Der „Angriff“ basiert darauf, die Datei zu klauen, in der die Host-ID steht. Insofern entspricht das Verfahren exakt dem Vorgang, sich an einer Website mit Username und Passwort anzumelden, die eine Option „[X] angemeldet bleiben“ bietet und daraufhin einen Cookie setzt, der eine lange Gültigkeit hat oder sogar nie verfällt: Die ursprünglichen Zugangsdaten werden ersetzt durch einen anderen Authentifizierungsmechanismus, der unabhängig von den Zugangsdaten besteht. Den Cookie kann ein Trojaner stehlen – und damit die Identität des Bestohlenen.
Und auch in einem weiteren Punkt gleicht die Dropbox-Authentifizierung Cookies: Der Sicherheitsexperte, der die „Lücke“ aufdeckte, verweist nämlich darauf, dass nicht einmal das Ändern des Passworts helfen würde, denn: Das wirkt sich nicht auf die Host-ID aus, die völlig eigenständig als Authentifizierung dient. Man könnte also sogar formulieren: Man braucht die Anmeldung mit Benutzername und Passwort nicht zur Nutzung der Dropbox, sondern lediglich zur Generierung der Host-ID; am Webinterface analog dazu zur Generierung des Cookies.
Benutzern muss doch klar sein, dass, wenn sie ihren Rechner rebooten, ihr Smartphone aus- und wieder einschalten … dass, wenn dann trotzdem der Zugriff auf die Dropbox auf „magische“ Weise immer noch ohne Eingabe irgendwelcher Zugangsdaten funktioniert, irgendeine Art von Authentifizierung hinterlegt sein muss. Dass das nicht übermäßig sicher ist, kann da doch ernsthaft keine Überraschung sein; dafür hat’s doch wohl bitte keinen Experten gebraucht, der das „aufdeckt“, sondern nur etwas gesunden Menschenverstand.
In der Sicherheitstechnik kennt man im Grunde drei Möglichkeiten der Authentifizierung: Geheimes Wissen (z. B. ein Passwort), Besitz (z. B. ein Haustürschlüssel) und Biometrie (körperliche Merkmale, die in der Regel nur schwer kopierbar oder fälschbar sind). Die Übergänge sind hier fließend: Melde ich mich an einem Dienst mit einem Passwort an, stellt jenes geheimes Wissen dar, das man mir nicht stehlen kann, sondern mich höchstens zur Preisgabe zwingen kann. Speichere ich das Passwort aber ab, z.B. im Browser oder sonstwo, mutiert es zu Besitz – man muss mich nicht mehr foltern; man muss mir nur noch die Datei klauen, in der das Passwort steht.
Es sollte keine Überraschung sein, dass jedes dieser Verfahren für sich genommen schwach ist. Menschen kompromittieren geheimes Wissen, in dem sie sich Trivialpasswörter ausdenken, überall das gleiche Passwort nehmen oder es gleich durch Aufschreiben oder Abspeichern in Besitz konvertieren. Besitz kann man stehlen; Besitz von klassischen Gegenständen setzt zumindest schon mal einen Einbruch voraus, Besitz von Dateien schon nur noch einen Trojaner auf dem Rechner, und wenn ich mir anschaue, wieviele Leute nicht mal ihr Betriebssystem aktuell halten und bei wievielen Freunden ich schon Malware von der Platte kratzen durfte, halte ich „Besitz“ schon fast für die fahrlässigste Möglichkeit der Authentifizierung. Biometrie allein bringt’s auch nicht – die Geschichten, wo Computer Menschen eben gerade nicht zuverlässig erkennen bzw. umgekehrt zuviele Menschen als zu einem biometrischen Merkmal passend erkennen, gibt es mehr als genug. Wir selbst waren eine Zeitlang in einem Rechenzentrum mit Fingerabdruckscanner und haben in drei Vierteln der Fälle in der Sicherheitsschleuse festgehangen, weil der Scanner uns nicht korrekt erkannte. Umgekehrt dürfte der Fingerabdruck des früheren Innenministers Schäuble spätestens seit der Veröffentlichung praktischer Fingerabdruck-Klone in der Datenschleuder, der Zeitschrift des CCC, eins der am häufigsten kopierten biometrischen Merkmale sein.
Was man also braucht, um Sicherheit zu erhöhen, sind Kombinationen von Verfahren. Das ist auch gar nicht weiter kompliziert: Jeder, der schon mal einen Geldautomaten benutzt hat, hat damit beispielsweise bereits die Kombination aus Besitz (ec-Karte) und geheimem Wissen (PIN) angewendet – keins davon hätte ihm alleine schon Bargeld verschafft. Selbst Kombinationen aus zwei identischen Verfahren sind sicherer als eins allein – um im Bankenumfeld zu bleiben: Mit einer PIN komme ich zwar ins Onlinebanking rein; um auch Überweisungen zu tätigen, brauche ich aber auch eine TAN. Mit einer TAN ohne PIN komme ich umgekehrt aber nicht mal ins System. Mit dem zunehmenden Umbau der Systeme auf TANs, die aufs Handy geschickt werden oder die man mit einem optischen Leser generiert, der wiederum die eingesteckte ec-Karte voraussetzt, wird hier verstärkt geheimes Wissen mit Besitz (Handy, oder TAN-Generator mit eingesteckter ec-Karte) gekoppelt.
Auch am Rechner gibt es schon lange Beispiele für Kombinationsverfahren: Browser, in denen man Passwörter abspeichern kann (womit die Datei, in der sie gespeichert werden, das Passwort zu Besitz mutieren lässt), können diese Datei auch verschlüsseln. Rufe ich nun den Browser auf und möchte eins der gespeicherten Passwörter nutzen, muss ich zunächst das Passwort eingeben, um die Passwortdatei zu entschlüsseln – Besitz und Wissen. Wer mit SSH-Keys arbeitet, wird diese typischerweise ebenfalls verschlüsselt haben und einen SSH-Agent starten, der zunächst die Passphrase zur Entschlüsselung des Keys abfragt und dann so den als Datei hinterlegten Key nutzbar macht – Besitz und Wissen.
Ich sehe also nicht, wo bei Dropbox da jetzt die Sicherheitslücke liegen soll. Es mag vielleicht irritierend sein, weil für den User nicht transparent ist, dass die Anmeldung faktisch via Besitz (Datei mit Host-ID) und nicht via Wissen passiert, weil sie nicht wissen, wie genau das alles im Hintergrund funktioniert. Aber auch wenn der Dropbox-Client einfach nur die Zugangsdaten in einer Datei abgespeichert hätte, wäre Wissen zu Besitz geworden, nur mit dem Unterschied, dass dann das Ändern des Passworts des Dropbox-Accounts Wirkung zeigen würde. Aus technischer Sicht finde ich den Unterschied allerdings zugegebenermaßen marginal. Wer häufiges Ändern von Passwörtern ernsthaft als „Sicherheitsmethode“ ansieht, dem ist vermutlich egal oder nicht bewusst, dass bis zur Passwortänderung schon längst alle möglichen Daten abgeschnorchelt oder gar unbemerkt verändert worden sein können. Die Sicherheit ist schließlich mit dem Einbruch kompromittiert – eine spätere Passwortänderung kann das nicht mehr ungeschehen machen.
Dropbox trägt also eigentlich nur an einem Schuld: Dass sie kein Kombinationsverfahren für die Authentifizierung forcieren. Dabei wäre es doch nun ein Leichtes, die Datei mit der Host-ID zu verschlüsseln und als Basis für eine Entschlüsselung ein vom User eingegebenes Passwort zu nehmen oder meinetwegen auch nur ein paar mit dem Finger aufs Smartphone geschmierte Linien – wobei eben wichtig ist, dass das nicht einfach dergestalt realisiert wird, dass die Software die Datei mit der Host-ID „freigibt“, sondern schon tatsächlich so, dass die Datei mit der Host-ID damit so verschlüsselt ist, dass der Besitz der Datei alleine tatsächlich nicht ausreicht, auch wenn man diese „hintenrum“ kopiert.
Aber vermutlich wäre das den meisten schon zu kompliziert. Man lobt Dropbox ja nun vor allem wegen seiner Einfachheit. Dem Sicherheitsexperten gehört insofern Dank, als dass er vielleicht ein wenig Sensibilität dafür weckt, wie Authentifizierung tatsächlich funktioniert. Das ändert aber nichts daran, dass die Mehrheit der User, wenn sie nicht gezwungen wird, vermutlich immer die bequemste Authentifizierung wählen wird, nämlich „merk dir meine Daten für immer und lass mich dann in Frieden“. Hieraus dann speziell Dropbox einen Vorwurf zu machen, halte ich für unredlich und an der Sache vorbei.
Dass die Host-ID bei einem Passwortwechsel nicht erneut angefragt wird und sich auch ändert, stört mich jetzt aber trotzdem. Ansonsten stimme ich mit dem Artikel überein.
Für mein nächstes Projekt werde ich evtl. mal das hier testen: https://store.yubico.com/
HERVORRAGENDER Artikel ! Herzlichen Glückwunsch !
Ich kommentiere normalerweise kaum … aber der hier ist wirklich der hit ! Alle Facts beachtet, Hintergrundwissen eingebaut, super getextet … Vorbildliche Arbeit !
Vielen Dank ! und einen tollen Tag
DJ