Hallo,

»… my former employer LivingSocial used in-browser crypto to encrypt credit card numbers in-browser with their payment processor’s public key«
»In this approach, there’s an implicit trust relationship between the user and the site they’re accessing. What we see happening here is cryptography being used to protect the web site’s interests, not the user’s. For this purpose, in-browser crypto is great!«

Das lese ich so, dass kryptografische Übertragung von Textnachrichten eigentlich prima möglich ist?

Das lese ich anders. Wichtig ist hier »protect the web site’s interests, not the user’s«. Das Übertragen von verschlüsselten Textnachrichten zwischen Usern wäre eine »user’s interest«.

Was der Text als Beispiel bringt, hat damit wenig zu tun: Kreditkartendaten werden clientseitig mit einem Public-Key des Payment-Providers verschlüsselt. Das bieten verschiedene Payment-Provider an und das haben wir auch schon einmal für Kunden implementiert.

Es gibt nur einen Grund, warum man das tut: Datenschutzgesetze. Wenn man Zahlungsdaten auf den eigenen Servern speichert oder sie auch nur kurzzeitig im Speicher hält, muss man gewissen Sicherheits- und Datenschutzrichtlinien genügen. Das ist ein teurer Zertifizierungsprozess, den man sich nicht unterziehen will, wenn man die Daten nicht im Klartext braucht, sondern sie direkt synchron an einen externen Payment-Provider weitergibt.

Wichtig ist hier: Es bietet für die User wenig zusätzliche Sicherheit. Es besteht immer das Problem, Daten direkt beim Client abzugreifen, z.B. durch XSS. Clientseitige Verschlüsselung ändert daran nichts. (Daher ist die »large laundry list« nötig, um das möglichst zu verhindern.) Die JavaScript-Verschlüsselung soll hier nur dem Anbieter das Leben vereinfachen.

Mathias