nicht angemeldet
Verschlüsselung
Hi,
ich bin gerade auf eine Website gestoßen, die eigentlich genau die Funktionalität anbietet, die ich hier vor ein paar Wochen beschrieben habe.
Bei der o.g. Website https://www.stackfield.com/ kann man unter https://www.stackfield.com/de/security nachlesen "Wie funktioniert die Verschlüsselung?".
Das ist doch genau das, was ich in meinem Thread damals beschrieben habe. Heißt das, dass das auf dieser Website genauso "sinnlos" ist?
MfG Naps
-
Tag,
ich bin gerade auf eine Website gestoßen, die eigentlich genau die Funktionalität anbietet, die ich hier vor ein paar Wochen beschrieben habe.
auf den ersten Blick ja, aber das, was du da beschrieben hast, ist nun schon sehr allgemein gehalten.
https://www.stackfield.com/de/security nachlesen "Wie funktioniert die Verschlüsselung?".
Das ist doch genau das, was ich in meinem Thread damals beschrieben habe. Heißt das, dass das auf dieser Website genauso "sinnlos" ist?
Dem kurzen Überfliegen nach wurden dir zwei Varianten dargelegt:
1. Verschlüsselung auf dem Server: Sinnlos. Wozu einen Schrank abschließen, wenn man den Schlüssel vorm Schrank liegen lässt?
Wird in den Server eingebrochen, hat der Unhold auch auf den Schlüssel zugriff, denn der muss sich ja auf dem Server befinden, um auf dem Server ver- und entschlüsseln zu können. Man kann den Zugriff zwar durchaus erschweren, aber das grundsätzliche Problem bleibt.Hinzu kommt, dass eine Verschlüsselung im Server nur gegen Einbruch in den Server in Stellung gebracht wird. Der Transportweg zwischen Server und Client wird damit nicht gesichert. Im dümmsten Falle transportiert man seine Goldbarren auf dem Eselsrücken zum Banktresor …
2. Verschlüsselung im Client: Sinnvoll, wenn auch mit den Einschränkungen, das a) der Client meist ein unsicheres Feld ist und b) Verschlüsselung im Browser bzw. mit Javascript schwierig bis unmöglich umzusetzen sind.
Stackfield verschlüsselt im Client. Über a) kann man im Einzelfall diskutieren, für b) scheint Stackfield eine Lösung gefunden zu haben (oder Stackfield setzt eigene Client-Software statt des Webbrowsers ein).
-
Meine Herren!
Bei der o.g. Website https://www.stackfield.com/ kann man unter https://www.stackfield.com/de/security nachlesen "Wie funktioniert die Verschlüsselung?".
Den interessanten Teil kann man da leider nicht nachlesen. Dort steht geschrieben, dass HTTPS die Kommunikation zwischen Server und Client verschlüsselt, und dass ein weiteres Verschlüsselungsverfahren für die End- zu End-Kommunikation verwendet wird. Welcher Algorithmus dafür genutzt wird, wie evtl. Schlüssel generiert und zwischen den Pateien ausgetauscht werden, sodass nicht einmal der Webserver selbst von ihnen erfährt, ist leider nirgends erklärt. Ich habe mal eine Mail an den Support geschickt und danach gefragt. Ich bin gespannt auf die Antwort.
--
“All right, then, I'll go to hell.” – Huck Finn-
Meine Herren!
Ich habe mal eine Mail an den Support geschickt und danach gefragt. Ich bin gespannt auf die Antwort.
Die kam gestern Abend: Die End- zu End-Verschlüsselung findet mit RSA statt. Die Schlüssel werden vom Client generiert, also von einer JavaScript-Implementation. Die Schlüssel werden zum gegenseitigen Austausch selbst nochmal mit AES verschlüsselt, den Schlüssel für letzteren Algorithmus wird von Stackfield das Masterpasswort genannt. Das Masterpasswort wird nicht von Stackfield verwaltet, dieses muss der Anwender sich merken.
--
“All right, then, I'll go to hell.” – Huck Finn-
Moin 1UnitedPower,
Die kam gestern Abend: Die End- zu End-Verschlüsselung findet mit RSA statt. Die Schlüssel werden vom Client generiert, also von einer JavaScript-Implementation.
Urghs, keine gute Idee, aus diversen Gründen. Hier ein paar davon:
- sicheres ausliefern von JS an den Browser ist ein Henne-Ei-Problem. Man vertraut dem Dienste-Anbieter nicht, dass er die Daten sicher verwaltet und will sie deshalb im Browser verschlüsseln. Also kann man auch nicht davon ausgehen, dass der JS-Code sicher ist: er könnte von einem Angreifer abgegriffen, verändert oder ersetzt worden sein.
- der Browser ist (noch) keine geeignete Umgebung, um Kryptografie zu betreiben, aus mehreren Gründen:
- der Code kann sich im Laufe der Session ändern (JS-Code kann sich aus mehreren HTTP-Requests zusammen setzen, jeder Request kann den Code ändern oder überschreiben, usw, pp).
- die JS-Engine selber angegriffen werden, beinahe alle der neueren Sicherheitslücken in Browsern lassen sich auf JS zurückführen
- die Art und Weise, wie die Umgebung sich verhält, kann sogar zur Runtime geändert werden
- es fehlen wichtige Elemente in Browser-JS, etwa kryptografischer Zufall (das ist extrem wichtig, schwacher Zufall führt zu schwachen oder vorhersagbaren Keys; es hat seinen Grund, dass die NSA versucht hat, schwachen Zufall in die Standards einzuschläusen) oder ein sicherstellen, dass Speicher auch wirklich weg ist, wenn man ihn nicht mehr braucht (Stichwort Garbage Collection) oder auch nur ein Key Store
- die Tatsache, dass sich das Verhalten der Umgebungen massiv voneinander unterscheiden, abhängig von OS, Browser, Hardware, installierter Software, usw, pp (siehe z.B. canvas fingerprinting)
Ich könnte mich noch deutlich länger darüber auslassen, warum Crypto im Browser nicht sinnvoll ist, aber dazu gibt es wirklich schon genug Artikel im Web, geeignete Stichworte dürften „browser cryptography critics“ sein.
LG,
CK-
Meine Herren!
Ich könnte mich noch deutlich länger darüber auslassen, warum Crypto im Browser nicht sinnvoll ist, aber dazu gibt es wirklich schon genug Artikel im Web
Diesen hier möchte ich empfehlen: http://matasano.com/articles/javascript-cryptography/
--
“All right, then, I'll go to hell.” – Huck Finn
-
-