Webmail mit PGP / RSA-Unterstüzung

Joel

Joel

Legendäres Mitglied
Hallo,

Heute morgen ist mir eine kleine Idee eingefallen.

Fast alle Nutzer versenden E-Mails unverschlüsselt und lagern ihre ganzen Daten auf irgendwelchen Servern. Obwohl es schon fast ein offenes Geheimnis ist, dass diese E-Mails vom Staat (z.B. USA/UK/Australien/etc.) und evtl. auch von Hackern gelesen werden können.

Meine Idee wäre ein Webclient für E-Mails (wie GMAIL), der es unterstützt E-Mails verschlüsselt zu versenden und zu empfangen. Dabei sollen aber die Daten nicht auf dem Server entschlüsselt werden, sondern auf dem Client via JavaScript. Somit hätte auch der Server-Betreiber keinen Zugriff auf die Mails.

Die nötigen Private-Keys würden z.B. in Cookies verschlüsselt gespeichert. Könnten aber auch auf dem Server verschlüsselt gespeichert werden und auf dem Client mit dem Benutzerpasswort entschlüsselt werden.

(Auf dem Server würde dann nur der Hash des Benutzerpasswortes, der verschlüsselte Private Key, der Plublic Key und die verschlüsselten Mails liegen)

http://www-cs-students.stanford.edu/~tjw/jsbn/
http://www.ohdave.com/rsa/
http://www.cs.pitt.edu/~kirk/cs1501/notes/rsademo/

Vorteile:
- Verschlüsselung einfach und für jeden Einsetzbar, ohne spezielle PC-Kentnisse.
- Es muss keine Software installiert werden.
- Per Webmail auf jedem PC Nutzbar.
- Daten sind sicher auf dem Server (da die Mails auch für Server-Betreiber verschlüsselt sind und erst beim Client entschlüsselt werden)
- Daten sind auch sicher auf dem Client (da sie nirgends gecached werden und die Private-Keys in den Cookies ebenfalls verschlüsselt sind mit dem Passwort des Nutzers).

Nachteile:
- JavaScript entschlüsselung dauert länger.. der Nutzer müsste ca. 6 Sekunden warten bis sein E-Mail entschlüsselt ist.

Was denkt ihr über die Idee?

Ich werds nicht realisieren, aber vielleicht könnte jemand von euch die Idee realisieren..

Gruess,
Joel
 
Hi,

Finde ich eine gute Idee, nur gibt es das schon lange
wink.gif
(ausser ich habe dich falsch verstanden). Ich setze Horde für sämtliche Kunden ein, dabei kann man direkt im Webmail PGP oder S/MIME aktivieren und zwar kostenlos. Die Verbindung kann sowohl per SSL wie auch normal erfolgen... was will man mehr?

Gruss Marc

 
QUOTE
Finde ich eine gute Idee, nur gibt es das schon lange (ausser ich habe dich falsch verstanden). Ich setze Horde für sämtliche Kunden ein, dabei kann man direkt im Webmail PGP oder S/MIME aktivieren und zwar kostenlos. Die Verbindung kann sowohl per SSL wie auch normal erfolgen... was will man mehr?


Danke für die Info
wink.gif
.

Auch gut, dann muss ich das nicht mehr Proggen.

Ich kenne Horde schon, wusste nicht, dass es das dort gibt. Der Horde-Webclient sieht aber auch ziemlich hässlich aus, da setz ich lieber auf GMail auch wenns keine Verschlüsselung hat..

Gruess,
Joel
 
QUOTE (Joel @ Do 19.4.2007, 11:48) Ich kenne Horde schon, wusste nicht, dass es das dort gibt. Der Horde-Webclient sieht aber auch ziemlich hässlich aus, da setz ich lieber auf GMail auch wenns keine Verschlüsselung hat..

Bei Horde kann man eigentlich alles anpassen (auch wenn das Tool wirklich etwas in die Jahre gekommen ist vom Design her), aber trotzdem, ich bleibe bei Horde
wink.gif
.

gruss marc
 
QUOTE Der Horde-Webclient sieht aber auch ziemlich hässlich aus, da setz ich lieber auf GMail auch wenns keine Verschlüsselung hat..


Das zeigt doch gut warum so etwas keine Massenanwendung ist. Die meisten wollen es bequem haben (geht mir genauso).
 
Also ich finde auf dem Server gespeicherte Private Keys sind ein grosses Sicherheitsrisiko und schreien geradezu danach missbraucht zu werden.
Für mich ein klares No-Go.
 
QUOTE
Also ich finde auf dem Server gespeicherte Private Keys sind ein grosses Sicherheitsrisiko und schreien geradezu danach missbraucht zu werden.
Für mich ein klares No-Go.


Darum sind sie ja auch verschlüsselt. Die Private Keys würden auf dem Client generiert und verschlüsselt auf dem Server gespeichert...
 
QUOTE Also ich finde auf dem Server gespeicherte Private Keys sind ein grosses Sicherheitsrisiko und schreien geradezu danach missbraucht zu werden.
Für mich ein klares No-Go.


Könnte man das nicht so lösen, dass die Keys jeweils geändert werden.

Das würde dann so funktionieren wie bei meinem Ebanking. Ich hab da so ein taschenrechnerähnliches Teil, wo ich einen auf der Login-Seite der Bank angezeigten Code eintippen muss. Danach zeigt mir dieses Kästchen einen weiteren (anderen) Code an. Diesen Code muss ich dann wieder online einfügen.

Ich benutze also jedesmal einen anderen Code.

Würde das gehen?
 
Das Problem ist erstens, egal ob die privaten Key verschlüsselt auf den Server gespeichert werden, dass (1) der Kunde dem Anbieter vertrauen müsste und (2.1) könnte ein Angreifer mit einem Mal alle Schlüssel klauen - da ja auch die Anwendnung die privaten Schlüssel zur Nutzung entschlüsseln muss -, bzw. (2.2) der Angreifer kann durch reines Passwortraten den Schlüssel benutzen, was bei richtiger Verwendung der asymmetrischen Verschlüsselung nicht möglich wäre.

Das Problem, dass die Verbindung immer verschlüsselt sein muss, ist minimal, ein vernünftiges SSL Zertifikat kaufen und richtig einbinden.




QUOTE (Andi Nigg @ Do 19.4.2007, 15:07)[...]
Könnte man das nicht so lösen, dass die Keys jeweils geändert werden.

Das würde dann so funktionieren wie bei meinem Ebanking. Ich hab da so ein taschenrechnerähnliches Teil, wo ich einen auf der Login-Seite der Bank angezeigten Code eintippen muss. Danach zeigt mir dieses Kästchen einen weiteren (anderen) Code an. Diesen Code muss ich dann wieder online einfügen.
[...]

Wozu möchtest Du dann das Ganze so machen. So wird das doch schon wieder komplizierter und Online-Backing mittels HBCI ist auch nichts anderes als eine asymmetrische Verschlüsselung, können die Bankkunden auch bedienen und ist wesendlich sicher als irgendein TAN-Verfahren.
Dann wäre es doch eigentlich besser der Benutzer bekommt einen vernünftigen E-Mail-Client mit einer einfachen und verständlichen Anleitung in die Hand gedrückt.
 
QUOTE
Das Problem ist erstens, egal ob die privaten Key verschlüsselt auf den Server gespeichert werden, dass (1) der Kunde dem Anbieter vertrauen müsste und (2.1) könnte ein Angreifer mit einem Mal alle Schlüssel klauen - da ja auch die Anwendnung die privaten Schlüssel zur Nutzung entschlüsseln muss


So wie ich das beschrieben habe bekäme nur *die lokale JavaScript-Anwendung* den unverschlüsselten privaten Key jemals zu Gesicht. Die ganze Ver-/Entschlüsselung soll auf dem Client passieren.

Mit strikten Regeln für das Passwort (z.B.min 11 Zeichen mit GrossKleinBuchstaben und Z4hlen) wäre die Chance für einen Erfolg bei einer Bruite-Force-Attacke gleich 0.

Da JavaScript immer OpenSource ist, könnten auch erfahrene Anwender den Code analysieren und sehen, dass niemals vertrauliche Daten zum Server gesendet würden.
 
QUOTE (Joel @ Do 19.4.2007, 16:59)[...]
So wie ich das beschrieben habe bekäme nur *die lokale JavaScript-Anwendung* den unverschlüsselten privaten Key jemals zu Gesicht. Die ganze Ver-/Entschlüsselung soll auf dem Client passieren.
[...]

Du hast jedoch auch das geschrieben:

QUOTE (Joel @ Do 19.4.2007, 11:32)
Darum sind sie ja auch verschlüsselt. Die Private Keys würden auf dem Client generiert und verschlüsselt auf dem Server gespeichert...

Welche Aussage stimmt denn nun? Oder wie genau stellst Du Dir das vor?



Problem 1 würde jedoch weiterhin bestehen bleiben, selbst wenn JavaScript nur die lokale Datei ausruft. Hier tauchen aber auch neue Probleme auch, JavaScript dürfte nach den Sicherheitseinstellungen aber nur auf lokale Dateien zugreifen (3), wenn die Erlaubnis des Benutzers vorliegt (Warnmeldung vom Browser oder standardmäßig geblockt).
Außerdem muss eine solche Anwendung sehr Gewissenhaft geschrieben werden (ergo lange und aufwändige Entwicklungsarbeit -> ISO 9126), die Entwickler sollten sich für "diesen Teil" in JavaScript und Sicherheitsaspekten sehr gut auskennen.
 
QUOTE
Welche Aussage stimmt denn nun? Oder wie genau stellst Du Dir das vor?


Beide...!? Die Aussagen passen doch perfekt zusammen...

Client:
1. Generiert Private-Key
2. Verschlüsselt Private-Key mit dem sicheren Benutzerpasswort.
3. Sendet verschlüsselten PK an den Server.


QUOTE
Problem 1 würde jedoch weiterhin bestehen bleiben, selbst wenn JavaScript nur die lokale Datei ausruft. Hier tauchen aber auch neue Probleme auch, JavaScript dürfte nach den Sicherheitseinstellungen aber nur auf lokale Dateien zugreifen (3), wenn die Erlaubnis des Benutzers vorliegt (Warnmeldung vom Browser oder standardmäßig geblockt).


Wieso sollte die JS-Datei auf lokale Dateien zugreiffen wollen...

--

Ich will jetzt auch nicht auf den Details rumtrampeln... war ja nur eine Idee
wink.gif
.
 
Du bist bestimmt nicht der erste mit dieser Idee, aber Punkt 3 (Client) von Dir, würde das Problem 2 wieder hervorrufen.

Deine Aussagen passen für mich nicht zu sammen, weil Du einmal behauptet, der private Schlüssel wird auf den Server gespeichert und einmal diese Aussage verneinst, indem Du meinst, das Problem 2 würde überhaupt nicht existieren.

Eine Passwortmethode ist nicht mit einer asymmetrischen Verschlüsselung zu vergleichen, dort soll das Passwort auch eher dazu dienen, dass die Schlüsseldatei nicht sofort benutzt werden kann, wenn diese mal in die falschen Hände gerät, so dass der Benutzer genug Zeit hat, diesen Schlüssel zu ersetzen.
 
QUOTE
Deine Aussagen passen für mich nicht zu sammen, weil Du einmal behauptet, der private Schlüssel wird auf den Server gespeichert und einmal diese Aussage verneinst, indem Du meinst, das Problem 2 würde überhaupt nicht existieren.


Ich habe gesagt, sie werden *nicht* *unverschlüsselt* auf dem Server gelagert. Solange das Benutzerpasswort gewisse Anforderungen erfüllt, kann der Private-Key verschlüsselt werden ohne dass dieser Vorgang rückgängig gemacht werden kann....

Du willst doch nicht behaupten, dass eine zufällige 1024-Bittige-Primzahl, welche z.B. mit dem Passwort (z.B. 11-Stellig mit Zahlen und KlEiN-GroSSbuchstaben z.B. AES) verschlüsselt wird von einem Angreifer entschüsselt werden kann!?

Somit wird jeder Private-Key mit einem anderen Passwort verschlüsselt und die PKs werden niemals auf dem Server entschlüsselt (sondern auf dem client, weil der server das passwort nicht kennt.). Der Server kennt das PW nicht und es wird niemals ohne Hash an den Server gesendet.

Wie gesagt, kann ein Angreifer niemals alle Schlüssel klauen, da jeder einzelne PK durch ein anderes PW geschützt ist.

Angriff durch Passwort errraten (Bruite Force) wird verhindert, indem es Regeln für Passwörter gibt (wie schon erwähnt). Das macht es *praktisch* *unmöglich*...
 
QUOTE (Joel @ Fr 20.4.2007, 6:29)[...]
Du willst doch nicht behaupten, dass eine zufällige 1024-Bittige-Primzahl, welche z.B. mit dem Passwort (z.B. 11-Stellig mit Zahlen und KlEiN-GroSSbuchstaben z.B. AES) verschlüsselt wird von einem Angreifer entschüsselt werden kann!?
[...]

Es kommt mir so vor als verstehst Du entweder das Problem nicht, oder Du verstehst asymmetrische Verschlüsselung im allgemeinen nicht. AES kommt auf 256 Bit Verschlüsselungsstärke.
Und ja, gehen kann das prinzipell schon, es hängt halt von der Verschlüsselung und der Passwortwahl ab, wie lange bzw. aufwendig das Ganze ist. Aber ist was anderes, mir geht es um folgendes bei meinen letzten Beitrag:




QUOTE (Joel @ Fr 20.4.2007, 6:29)
Ich habe gesagt, sie werden *nicht* *unverschlüsselt* auf dem Server gelagert. Solange das Benutzerpasswort gewisse Anforderungen erfüllt, kann der Private-Key verschlüsselt werden ohne dass dieser Vorgang rückgängig gemacht werden kann....

Ich denke, Du verstehst mich nicht richtig (und ich verstehe Dich bei Deiner Ausdrucksweise auch nicht wirklich, da Sie für mich irgendwie widersprüchlich ist):
Da ist ja gerade ein Problem, normalerweise überlässt man nicht mal einen verschlüsselten privaten Schlüssel einfach so jemanden anderen.

Auch denke ich nicht, dass Du meinst, die Verschlüsselung des privaten Schlüssel könne nicht rückgängig gemacht werden kann. Immerhin wäre dieser dann nicht mehr zu gebrauchen. Du siehst, bei einer solchen Ausdrucksweise kann es schnell zu missverständen.




QUOTE (Joel @ Fr 20.4.2007, 6:29)[...] Angriff durch Passwort errraten (Bruite Force) wird verhindert, indem es Regeln für Passwörter gibt (wie schon erwähnt). Das macht es *praktisch* *unmöglich*...

Da sag ich auch nicht viel gegen, aber es ist nicht so sicher, als wenn der private Schlüssel richtig eingesetzt wird und der Angreifer nicht nur das Password herauszufinden braucht. Nimm aber lieber mind. 12 Zeichen.




Aber hier verstehst Du mich vermutlich nicht richtig, oder ich Dich nicht. Letztendlich ist es mir aber auch egal, es ist Dein Risiko.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben