django-crypted-fields

[jens]

Ich hab mal wieder eine vielleicht bekloppte Idee

Wie wäre es, wenn man eine Reuseable-App baut, mit der man Clientseitig per JavaScript Daten für die DB transparent verschlüsselt?

Wozu? z.B. um alle Einträge eines Kalenders nur verschlüsselt auf dem Server zu speichern und nur auf dem Client per JS unverschlüsselt anzuzeigen.

Also genau entgegengesetzt von dem was 90% der Leute machen: Einfach den Google-Kalender nutzten und somit die Daten in der Cloud zu "verteilen"...

Ich stelle mir das so vor: Auf dem Client haben wir ein "Secret" (Im einfachsten Fall ein Passwort, was der User eingeben muß und was für die Session gültig ist)
Im Django-Model markiert man auf irgendeine Weise ein Model-Field. Damit erreicht man, das ein JS Skript beim rendern vom HTML Code aktiv wird. Wenn man nun das Feld per Admin/ModelForm editiert, wird es per JS beim senden verschlüßelt und so gespeichert. Beim nächsten editieren/anzeigen, wird es auf dem Client direkt per JS entschlüßelt.

Soweit zur groben Idee. Wie gesagt, als Einsatzgebiet ist mit eine Kalender-App eingefallen. Also ehr ein Dienst der nur für einen selber oder für einen kleinen Freundeskreis zuständig ist.

Sind natürlich einige Fragen zu klären, aber ich denke Grundsätzlich wird das schon so funktionieren. Ist vom Prinzip her das selbe was Firefox-Sync macht.

Hab noch nicht gesucht, ob es schon ein Projekt gibt, was genau das macht. Kennt da jemand was?

Meinungen dazu?

[jens]

Bischen gesucht und http://stackoverflow.com/questions/1087 ... lient-side gefunden, was auf ein PHP Projekt verweist -> http://sebsauvage.net/wiki/doku.php?id=php:zerobin bzw. https://github.com/sebsauvage/ZeroBin

Ein wenig in der Richtung scheint auch https://pypi.python.org/pypi/django-pstore zu sein. Allerdings ver/entschlüsselt man dort anscheinend nicht im Browser, sondern mit einem Kommandozeilen-Client-Programm.

Interessant ist evtl. http://www.fduran.com/blog/whisperpassword/

Denke da wird es noch mehr geben... Aber gerade keine Zeit, weiter auf die Suche zu gehen...

[lunar]

@jens Ich halte wenig von der Idee. Einem gezielten Angriff hält dieser Ansatz nicht stand, denn ein MITM kann den Javascript-Quelltext zur Verschlüsselung während der Übertragung einfach austauschen, und somit den Client dazu bewegen, die Daten unverschlüsselt zu übertragen.

[jens]

Schon klar, das es keine 100% Sicherheit bietet. Wie auch. Allerdings spricht nichts dagegen zusätzliche Verschlüsselung zu nutzten. Sprich https
Doch MITM ist generell ein Problem. Gerade dann, wenn man Daten auf einen Server legt. Auch wenn es der eigene sein sollte, kann man letztlich nicht vollkommen sicher sein, das keine dritten Zugriff haben. Eigentlich kann man vollkommen sicher sein, das Dritte zugriff habe. Der Provider

Wenn man allerdings sieht, das anscheinend die halbe Welt ihre Dinge mit Google und Facebook teilen und da kein Problem mit haben, rückt es das ins andere Licht...

Um beim Kalender zu bleiben: Natürlich wäre es sicherere man betreibt das ganze auf dem eigenen Server zuhause und nutzt DynDNS, Port-Weiterleitung usw.

[lunar]

@jens Betrachte HTTPS als Lösung für das MITM-Problem. Beginnst Du, an HTTPS zu zweifeln, kannst Du Webprogrammierung auch gleich einstellen.

Und ungeachtet dessen, was oft kolportiert wird, ist ein Angriff gegen HTTPS noch immer verhältnismäßig aufwendig, vor allem, wenn er unbemerkt stattfinden soll. Dann braucht man nämlich gefälschte Zertifikate, an die man nicht so einfach und nicht ohne erheblichen finanziellen Aufwand gelangt.

Deine Idee dagegen ist trivial zu brechen, wenn man den Verkehr manipulieren kann. Mithin ist sie keine[/i] Transportverschlüsselung.

Erst wenn Du sie über HTTPS betreibst, ist sie – ein klitzekleines bisschen – von Wert, aber eben nicht als Transportverschlüsselung, sondern als Datenverschlüsselung gegenüber dem Provider. Die Notwendigkeit einer solchen Verschlüsselung allerdings impliziert, dass Du dem Provider misstraust. Was wiederum zur Frage führt, warum Du Deine Anwendung dann überhaupt bei diesem Provider betreibst.

Denn der kann trotz dieser Maßnahme mitlesen, wenn er denn wollte. Schließlich liegt die Anwendung auf seinen Servern, und er kann somit in der Theorie beliebige Teile austauschen, einschließlich dieser „Verschlüsselungskomponente“.

TLDR: Deine Idee ist keine Verschlüsselung, nicht einmal eine zusätzliche, sondern ein billiger Taschenspielertrick. Wenn Dir Dein Kalender so wertvoll ist, dass Du ihn wirklich schützen möchtest, dann speichere ihn in einer ICS-Datei in einem verschlüsselten Dateisystem, und synchronisiere dieses über Google Drive oder Dropbox. Ansonsten kannst Du Dir die Mühe sparen.

Aber gut, ist ja Deine Zeit, die Du mit dieser Implementierung verschwendest…

[Sirius3]

@lunar: Du siehst das ganze sehr negativ.
Gehen wir mal davon aus, nicht die ganze Welt hat sich gegen Dich verschworen und Dir einen Spybrowser untergeschoben, der genau Deine Aktivitäten mitprotokolliert ohne dass Du eine Chance hast, dahinterzukommen.
Es gibt also den Serverbetreiber Goodwill, der damit Werbung macht, dass auf seinen Servern nur verschlüsselte Daten liegen und kein Schlüssel dazu, denn der bleibt allein in Deinem Browser.
Somit haben alle, die den Server hacken und die Daten ziehen nur einen Haufen Zufallszahlen erbeutet.
Sollten sie den ausgelieferten Javascript-Code manipulieren, so können n unabhängige Prüfclients, die ständig den Javascript-Code vom Server laden und ihn auf Veränderung prüfen, sofort Alarm schlagen. Diese Prüfclients können auch unabhängig vom Serviceprovider betrieben werden (CCC, TÜV, BMI). Die Wahrscheinlichkeit, dass diese alle gleichzeitig gehackt werden, geht also gegen 0.
Der paranoide Nutzer hat den ganzen Seitencode auswendig gelernt und prüft von Hand nach.

[jerch]

@Sirius3: Die Prüfung müsste man aber auf die HTML-Ressourcen ausdehnen - sonst kann man den Schutz mit einem weiteren <script>-Element oder inline-JS relativ einfach aushebeln.
Die versetzte Prüfung durch n Prüfinstanzen lässt theoretisch ein Zeitfenster möglicher Kompromittierung. Wirklich sicher bekäme man dies nur, wenn die Prüfinstanzen jede Anfrage prüfen würden (als eine Art vertrauenswürdiger Proxy oder Zwischenprovider), womit man beim Ausgangsproblem - ist der Provider vertrauenswürdig - wieder landet.

[lunar]

@Sirius3 Wir reden nicht über „N unabhängige Prüfclients“ beim CCC, TÜV, BMI, oder whatever, sondern über Jens' good ol' homegrow security snake oil.