Verschlüsseln von Daten von Benutzern in Webanwendungen

Question

Einige Webanwendungen, z. B. Google Docs, speichern Daten, die von Benutzern generiert wurden. Daten, die nur von ihrem Besitzer gelesen werden können. Oder vielleicht nicht?

Soweit ich weiß, werden diese Daten wie in einer entfernten Datenbank gespeichert. Wenn also jemand mit genügend Privilegien im Remote-System (zum Beispiel ein Systemadministrator) meine Daten lauern kann, könnte meine Privatsphäre kompromittiert werden.

Was könnte die beste Lösung sein, um diese Daten verschlüsselt in einer entfernten Datenbank zu speichern und nur der Eigentümer der Daten könnte sie entschlüsseln? Wie kann dieser Prozess für den Benutzer transparent gemacht werden? (Sie können das Kennwort des Benutzers nicht als Schlüssel zum Verschlüsseln seiner Daten verwenden, da Sie sein Kennwort nicht kennen sollten).

Answer 1

Wenn die Verschlüsselung/Entschlüsselung auf dem Server durchgeführt wird, gibt es keine Möglichkeit sicherzustellen, dass der Klartext nicht irgendwo in einer Protokolldatei oder Ähnlichem abgelegt wird.

Sie müssen die Verschlüsselung/Entschlüsselung im Browser mit JavaScript/Java/ActiveX oder was auch immer tun. Als Benutzer müssen Sie der Clientseite des Webdienstes vertrauen, die Informationen nicht unverschlüsselt an den Server zurückzusenden.

Carl

Answer 2

Nein, können Sie keine Passwörter verwenden, aber Sie können Passwort-Hashes verwenden. Bei Google Text & Tabellen geht es jedoch ausschließlich um die Freigabe. Bei einer solchen Methode müsste also eine Kopie des Dokuments für jeden Benutzer gespeichert werden.

Answer 3

Ich denke Carl, genagelt es auf den Kopf, aber ich wollte sagen, dass mit jeder Website, wenn Sie es vertrauliche/persönliche/privilegierte Informationen zur Verfügung stellen, dann müssen Sie ein gewisses Maß an Vertrauen haben, und es ist die Verantwortung des Dienstleisters, dieses Vertrauen aufzubauen. Dies ist eine dieser Fragen, die seit ihrer Einführung im Internet immer wieder gestellt wurde, und sie wird nur weiter wachsen, bis wir alle unsere eigenen SSL-Zertifikate auf unserem Fingerabdruck haben, und selbst dann müssen wir die Frage stellen "Woher weiß ich, dass der Finger noch am Benutzer hängt?".

Answer 4

Nun, ich würde einen Prozess ähnlich wie Amazons AWS betrachten. Sie authentifizieren sich mit einem privaten Kennwort, das nicht remote gespeichert wird. Nur ein Hash wird verwendet, um den Benutzer zu validieren. Dann generieren Sie ein Zertifikat mit einem der wichtigsten und lang erprobten Algorithmen und stellen dies von einer sicheren Seite bereit. Dann kann ein öffentlicher/privater Schlüsselalgorithmus verwendet werden, um Dinge für die Benutzer zu verschlüsseln.

Aber das Hauptproblem bleibt das gleiche: Wenn jemand mit genügend Privilegien auf die Daten zugreifen kann (sagen Sie: Ihren Server gehackt), sind Sie verloren. Bei genügend Zeit und Kraft könnte alles kaputt gehen. Es ist nur eine Frage der Zeit.

Aber ich denke, Algorithmen und Anwendungen wie GPG/PGP und ähnliche sind sehr gut bekannt und können so implementiert werden, dass Webanwendungen sicher sind - und die Benutzerfreundlichkeit auf einem Niveau hält, das der durchschnittliche Benutzer bewältigen kann.

bearbeiten Ich möchte mit @Carl und Unkwntech aufholen und ihre Anweisung hinzufügen: Wenn Sie sich nicht über die Website vertrauen, keine privaten Daten weggeben. Das ist sogar, bevor jemand ihre Server hackt ... ;-)

Answer 5

Auron gefragt: Wie generieren Sie einen Schlüssel für den Client zum Verschlüsseln/Entschlüsseln der Daten? Wo speichern Sie diesen Schlüssel?

Nun, der Schlüssel wird normalerweise von einem Passwort abgeleitet, das der Benutzer gewählt hat. Sie speichern es nicht, Sie vertrauen darauf, dass der Benutzer sich daran erinnert.Was Sie speichern können, ist vielleicht ein Salzwert, der mit diesem Benutzer verbunden ist, um beispielsweise die Sicherheit gegen Rainbow-Table-Angriffe zu erhöhen.

Crypto ist schwer zu bekommen ;-) Ich würde empfehlen, den Quellcode für AxCrypt und für Xecrets 'Off-line-Client zu sehen.

Carl