Jörg Reinholz: Umfrage zu assymetrischer Verschlüsselung mit Javascript

Beitrag lesen

Ich beschäftige mich ja nun schon einige Zeit mit der Konstruktion und Programmierung einer halbwegs brauchbaren Bibliothek für Logins.

Ein Aspekt des "halbwegs brauchbar" ist die verschlüsselte Übertragung der Passwörter und/oder des Benutzernamens.

Dazu habe ich jCryption gefunden. Erste Tests belegen: Geht zwar wenn man rausfindet, dass es bei dem dort gegenwärtig angebotenen Download ein Problem mit der Schreibweise der Dateinamen hat (was hier wohl ein Sicherheitsfuture ist, eben damit nicht jeder jCryption naseweis verwendet und als sicher anpreist), aber ...

Exkurs: Was jCryption macht? Ganz einfach. Die Formulardaten werden nicht direkt gesendet, sondern durch Javascript abgefangen. Das Javascript holt sich (warum auch immer so...) per Ajax den öffentlichen Schlüssel vom Server, verschlüsselt die Daten und sendet diese zum Server. Dort werden die Daten mit dem geheimen Schlüssel des Paars entschlüsselt. Das klingt erst mal gut aber ...

Durch einfaches Nachdenken komme ich darauf, dass ein relativ einfacher Man-in-the-Middle-Angriff möglich ist. Das weil es keine Möglichkeit gibt, die Schlüssel zu authentifizieren. Das heisst: Gelingt es einem Dritten einen Server zu installieren, der sich (im Netzwerk als transparenter Proxy oder via vergifteten DNS) als der angesprochene Server ausgibt und grinsend einen eigenen öffentlichen Schlüssel präsentiert, dann wird das Skript treudoof die Daten mit diesem verschlüsseln und an den Angreifer senden, der diese dann, einfacher geht es nicht, mit seinen eigenem geheimen Key entschlüsselt.

Und also die Benutzernamen und Passwörter im Klartext hat.

Jetzt gilt manchem "mit Verschlüsselung" sei immer noch sicherer als "ohne Verschlüsselung" weil nicht wirklich JEDER Hobbyangreifer zu der Attacke in der Lage ist. Aber stellt sich hier die nicht die Frage, ob ich jetzt künftige Benutzer der Bibliothek womöglich in falscher Sicherheit wiege, wenn ich eine solche, selbst für höchstens halbgare Hacker leicht zu umgehende Verschlüsselung mit in die Bibliothek einbaue und vor allem, ob künftige Verwender der Bibliothek dann nicht deren Benutzer ungerechtfertigt in Sicherheit wiegen (Mit Sätzen wie "Ihre Daten werden verschlüsselt übertragen, damit die niemand abfangen kann...")?

Readmes werden bei Sachverhalten, welche die unmittelbare Funktion nicht beeinträchtigen, ja gerne ignoriert...

Die Frage ist also:

Lasse ich das und verweise gleich auf https oder baue ich aus "markttechnischen Gründen" die ungeschützte Verschlüsselung in die Login-Bibliothek mit ein und warne in den "gar sorgfältig versteckten" README-Dateien deutlich davor, auf die Vertraulichkeit der Datenübertragung zu vertrauen?

Jörg Reinholz