[linux-l] Buchhaltung in der Cloud?!

[Volker Grabsch]

Liebe Liste,

ich wurde gerade darauf aufmerksam gemacht, dass man
neuerdings Buchhaltung in der Cloud machen kann:

    http://kontoblick.de/

Ein Freund fragte mich nach meiner Meinung zur der
Sicherheit solcher Dienste. Meine Antwort wurde etwas
länger, daher dachte ich mir, kann ich sie auch gleich
veröffentlichen.

Eure Meinung dazu würde mich interessieren.


1) Allgemeine Probleme von Webdiensten

Die Sicherheit einer lokalen Applikation kann der Webdienst
prinzipbedingt nicht erreichen:

Selbst wenn sie die Kryptographie ordentlich hingekriegt
haben sollten, kann ein Angreifer immer noch in die Server
eindringen und manipulieres JavaScript ausliefern. Ab da
kann er bei allen zukünftigen Logins die Passwörter der
User mitlesen, und deren Daten entsprechend entschlüsseln.

Eine lokale Anwendung kann zwar auch Sicherheitslücken
haben, aber die kann man zur Not immer noch in eine VM
stecken und Netzwerk-Zugriff abklemmen. Die Web-Applikation
hingegen kann man nicht am Kommunizieren hindern, und sie
ist rund um die Uhr am Netz und angreifbar. Außerdem: Wenn
zentral Daten von vielen Usern gesammelt werden, ist das
in viel attraktiveres Angriffsziel als bei Desktop-Rechnern,
wo ein Einbruch maximal die Daten _eines_ Users verspricht.


2) Verschlüsselung bei kontoblick

Das war allgemein, wenn sonst nichts schief geht. Konkret
bei "kontoblick" scheint aber noch mehr schief zu gehen:

Sie sagen, dass die Daten verschlüsselt in den DBs liegen,
und dass die Daten verschlüsselt übertragen werden. Damit
lassen sie bewusst offen, ob die Daten nur auf Clientseite
ver- und entschlüsselt werden, oder ob die Daten auch auf
Serverseite (vor dem Abspeichern) entschlüsselt werden können.

Offenbar ist letzteres der Fall, wenn man zwischen den Zeilen
liest, denn in ihren Privacy-Bestimmungen[1] schreiben sie:

    | Wie werden meine Daten ausgewertet?
    | [...]
    | Dies ermöglicht den statistischen Vergleich der eigenen
    | finanziellen Situation durch den Nutzer.

Das heißt: Mindestens die Kontenstände gelangen irgendwie
auf die Serverseite in auswertbarer Form. Würden sie 100%
clientseitige Verschlüsselung verwenden, wäre das gar nicht
möglich.


3) Anfängerfehler: Erstzugang unverschlüsselt

Ach ja, und natürlich ist die Webseite per Default via
HTTP, also unverschlüsselt, zu erreichen. Das heißt, viele
Anwender dürften die URL zur unverschlüsselten Seite in
ihren Bookmarks haben. Als Angreifer brauche ich daher gar
kein SSL zu hacken, sondern einfach nur den DNS umbiegen
und ne andere HTTP-Seite ausliefern. Klickt der User dann
zum Login in den abgesicherten Bereich, verlinkt der Angreifer
einfach auf eine geringfügig andere Domain, also nicht
"https://ssl.kontoblick.de/...", sondern zum Beispiel sowas wie:

    https://sslkontoblick.de/
    https://ssl-kontoblick.de/
    ...

Hauptsache, die Domain ist noch frei und der User merkt den
Unterschied nicht auf den ersten Blick. Das Zertifikat für
diese andere Domain kann sich der Angreifer offiziell bei
jeder SSL-Bude holen - ist ja seine eigene Domain. Das generelle
Problem ist: Wenn der initiale Zugang unverschlüsselt ist,
hat der Angreifer bereits gewonnen. Oder anders gesagt:
Nachträglich hinzugeschaltete Security bringt nichts. Was für
ein Anfängerfehler.


4) Fazit

Ich bin deshalb eher skeptisch, was die tatsächliche
Sicherheit dieses Dienstes angeht.


Gruß
Volker

-- 
Volker Grabsch
---<<(())>>---