noisefloor schrieb:
Hallo,
@themroc: besser wäre das wohl in einem eigenen Artikel aufgehoben. Würde auch die Wartbarkeit erhöhen.
Gruß, noisefloor
Ich mach mich bei Gelegenheit an die Arbeit für einen Artikel, die Arbeit habe ich mir ja schon gemacht.
Ich hole hier mal ein bisschen aus ... in der Hoffnung, das es jemand liest (ist also an niemand speziellen gerichtet, ich hatte heute Mittag etwas zu schnell auf den Senden - Button gedrückt!).
Das Thema "EncFs in der Cloud" betrifft einfach immer mehr Leute - wie ein aktueller, längerer Artikel in einem Blog der auf http://ubuntunews.de verlinkt ist und von entsprechend vielen Leuten gelesen wird, zeigt.
Ich schätze mal, dass die Anzahl der User die die Kombination von Owncloud (oder andere Clouds) und EncFs in Zukunft einsetzen, stark ansteigen wird. Das hängt natürlich mit der dateiweisen Verschlüsselung zusammen, die EncFS anbietet - was es für diesen Einsatz natürlich prädestiniert. Mit Sicherheit wird dies ein Ziel von Angreifern sein.
EncFs ist eine super Erfindung und einfach zu bedienen - besonders wenn man z.B. den EncFs-Manager von Gnome verwendet oder BoxCryptor. Das sollte jedoch nicht dazu verleiten, die Sicherheitsaspekte aus Bequemlichkeit auf die leichte Schulter zu nehmen, insbesondere wenn private Daten in die Cloud gestellt werden.
"[...] Verschlüsselt werden die Daten dabei mit einem grossen, in einer Datei vorliegenden Schlüssel, dem so genannten Volume Key. Dieser ist
nochmals mit einem Passwort geschützt, um Entschlüsselung bei Kenntnis des Volume Keys zu verhindern. [...]"
Zitat (Wikipedia)
De Facto liegt also der private Schlüssel von EncFs (Volume Key genannt) blank und für einen Angreifer zugänglich offen im Web - ob nun durch ein Passwort "geschützt" ist oder nicht. Dies lässt sich sehr einfach vermeiden, daher sollte man es einfach nicht nicht tun.
Passwortcracker leisten heute enormes. Den Volume-Key mit schwachem, ja selbst mit wenig starkem Passwort zu knacken ist für einen Angreifer nur eine Frage der Zeit. Hier liegt das Problem:
- Ein Angreifer kann völlig automatisiert in aller Ruhe die "encfs6.xml" auslesen und entschlüsseln!
- Und wie oft wechsel wohl ein Anwender diese Datei bzw. generiert den Schlüssel neu?: in der Regel nie!
- Wer verwendet einen starkes, zufallsgeneriertes 64bit-Passwort (Keypass, passwdgen)?: Wenige!
Es geht mir nur darum aufzuzeigen, dass der Key im Datenverzeichnis der Cloud vorhanden ist. Ob nun mit einem Passwort geschützt ist oder nicht, spielt dabei eine untergeordnete Rolle. Man kann jedoch durch das weiter oben gezeigte Verfahren ganz einfach verhindern, dass der volume Key in der Cloud landet, in dem man den Schlüssel an anderer Stelle auf dem Rechner belässt und verlinkt.
Der Key heisst noch dazu bei wahrscheinlich 99% aller Anwender ".encfs6.xml" (obwohl man diese auch umbenennen könnte). Noch dazu liegt er an definierter Stelle, ist also sofort eindeutig als solcher zu erkennen.
Private Schlüssel gehören im Grunde physikalisch auf einen externen Datenträger oder zumindest in ein besonders geschütztes (0400) oder verschlüsseltes Verzeichnis. Nur weil die Majorität der Benutzer das nicht so macht, heisst es leider nicht das es nicht Not tut. Was EncFs betrifft: es reicht, den Schlüssel in dem Moment zur Verfügung zu haben in dem man EncFs mounted. Danach wird er nicht mehr benötigt.
Ein einfaches Beispiel: Kein Mensch würde seine EC-Karte - die den elektronischen Schlüssel enthält - offen irgendwo hinlegen, mit dem Argument, dass diese ja durch ein Passwort verschlüsselt ist (PIN).
Nach erfolgreicher Entschlüsselung bei schwachem Passwort kann ein potentieller Angreifer die privaten Daten des Nutzers in aller Ruhe auslesen ohne dass dieser etwas davon mit bekommst. Da die meisten Anwender ihr Owncloud-Passwort und den EncFs Schlüssel nie ändern, steht die Owncloud für einen Angreifer wahrscheinlich sehr lange wie ein Scheunentor offen.
Bei steigender Nutzung von Cloudsystemen ist die Wahrscheinlichkeit hoch, dass Angreifer potentielle Lücken in Systemen automatisiert nutzen, um an Nutzerdaten zu gelangen.