Moin Moin!
Wenn sie dir vertrauen, wo ist dann das Problem, es unverschlüsselt zu speichern?
Provider, unzuverlässige Helfer, Hacker, Backup gelangt in Hände anderer ...
So lange wir über Webserver reden, wirst Du die Daten vermutlich auf dem Server ver- und entschlüsseln wollen. Dann ist alles, was ein Angreifer braucht, an einem Platz: Ver-/Entschlüsselungsmaschine, Schlüssel, und entweder Klartext oder Chiffrat. Sicherheitstechnisch ist das, um mal den Consultant raushängen zu lassen, SUBOPTIMAL.
Also brauchst Du einen anderen Ansatz: Die Daten des Benutzers kommen schon als verschlüsselter Datenblock am Server an, und gehen auch als verschlüsselter Datenblock wieder raus. Den Schlüssel behält der Benutzer und der kommt auch nie auf den Server.
Mitgedacht? Die Ver-/Entschlüsselungsmaschine ist aus dem Server rausgenommen, d.h. Du brauchst einen passenden Client, der das Ver- und Entschlüsseln sowie das Generieren eines Schlüssel(paar)s übernimmt.
Den Client samt Ver-/Entschlüsselungsmaschine kannst Du ganz normal per HTTP(S) ausliefern, und dann z.B. direkt im Browser laufen lassen. In reinem Javascript könnte das ETWAS langsam werden, Java ist oft nicht aktiviert, ein ActiveX-Control sperrt dich in die Windows-Ecke ein, Flash wäre noch eine Möglichkeit.
Wenn der Benutzerschlüssel als Datei vorliegt, scheiden Javascript (ohne sehr üble Tricks) und Flash sowie unsignierte Java-Applets aus. Der Rest (ActiveX-Controls und signierte Java-Applets) könnte auch auf die Datei zugreifen.
Mit allen Techniken (Javascript/AJAX, Java, Flash, ActiveX) könntest Du einen recht komfortablen Client bauen, der mehr an eine Native-Anwendung erinnert als an eine Website. HTTP(S) wäre dann nur noch Transportmedium für verschlüsselte Datenblöcke.
Ich gebe zu, das ist kein Projekt für ein Wochenende. Da geht definitiv mehr Zeit drauf.
Alexander
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".