nicht angemeldet
Umfrage zu assymetrischer Verschlüsselung mit Javascript
1 0
Umfrage zu assymetrischer Verschlüsselung mit Javascript
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
-
Hi,
Lasse ich das und verweise gleich auf https
Ja.
oder […]
Nein.
MfG ChrisB
--
Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/ -
Hi,
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.
Nicht nur die Logindaten müssen verschlüsselt werden sondern alle Daten. Wenn nur die Logindaten verschlüsselt werden ist zwar das PW rudimentär geschützt aber die Sessioncookies und alle übertragenen Daten (deren Zugriff durch den Login geschützt wird) sind mitlesbar. Damit ist eine gesonderte Verschlüsselung der Logindaten witzlos.
Durch die Nutzung von komplexem JS (dazu gehört Crypto zweifellos) können weitere Angriffssvektoren hinzukommen z.B. XSS. So ließe sich das PW unverschlüsselt abgreifen.
Dazu habe ich jCryption gefunden.
Da hat ein Crypto-Laie ein jQuery-Plugin mit ein paar PHP-Scripten zusammengeschustert. Erst jüngst hat das Google Security Team eine kritische Sicherheitslücke darin gefunden: indirekt wurden $_POST-Eingaben ohne Escaping in einen Shell-Command eingebettet. Ein unabhängiger Security-Audit hat nicht stattgefunden. Es gibt keine automatisierten Tests, wenig Contributors, kein richtiges Changelog usw.
Da sollten alle Alarmglocken läuten. Sogar abgesehen von den gravierenden Konzeptschwächen (MITM) wäre es gefährlich das einzusetzen. Das zeigt wieder, daß schlechte Sicherheit schlimmer ist als keine Sicherheit.
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
Eine Loginbibliothek sollte User Authentication bereitstellen. Nicht mehr und nicht weniger. "Do one thing and do it well". Transportverschlüsselung zw. Client und Server ist eine andere Aufgabe die mit SSL/TLS umsetzbar ist, nicht mit PHP und JS.
Harry
-
Ich danke Euch beiden. Ich selbst bin nämlich schon nach ein wenig Herumspielen und dem Erkennen der leicht möglichen Man-in-the Middle-Attacke aus weiteren Prüfungen ausgestiegen.
Jetzt kann ich Werbung damit machen, dass ich zwar leicht hätte Werbung mit einem falschen Sicherheitsgefühl machen können, dass ich das aber auch aus von anderen erkannten Gründen viel besser lasse und statt dessen auf HTTPS verweise. Entsprechende Angebote sind ja auch billiger als die hier zu erwartende Blamage meiner selbst, der das womöglich nutzenden und vor allem die dann notwendigen "Aufräumarbeiten".
Jörg Reinholz
-
Lieber Jörg Reinholz,
Ich danke Euch beiden. Ich selbst bin nämlich schon nach ein wenig Herumspielen und dem Erkennen der leicht möglichen Man-in-the Middle-Attacke aus weiteren Prüfungen ausgestiegen.
wie genau wäre Man-in-the-Middle bei einer HTTPS-Verbindung weniger "leicht" und weniger "möglich"?
Ich habe einmal damit experimentiert, eine HTML-Datei lokal auf einem Rechner zu speichern und dem darin enthaltenen JavaScript (darunter Passwort hart kodiert und CryptoJS) Daten zu einer Website zu übertragen, die die Daten nur dann annimmt, wenn das Datenpaket mit dem passenden Schlüssel dekodiert werden kann.
Da die HTML-Datei vom Client nicht aus dem Web angefordert werden kann, sondern eben lokal auf einem Rechner liegt, sehe ich darin einen Login-Ersatz, der POST-Aktionen möglich macht, die eine gewisse Automatisierung beim Datenübertragen zur Website ohne weitere Zusatzsoftware auf dem Client überhaupt ermöglicht.
Man korrigiere mich, wenn ich konzeptionell falsch liegen sollte, aber für einen solchen Fall sehe ich in CryptoJS durchaus einen Sinn.
Gerade sehe ich beim Verfassen des Postings, dass ich vielleicht auf Forge umsteigen sollte, da CryptoJS nicht mehr aktiv weiterentwickelt wird. Dabei war CryptoJS so schön "handlich"...
Liebe Grüße,
Felix Riesterer.
--
"Wäre die EU ein Staat, der die Aufnahme in die EU beantragen würde, müsste der Antrag zurückgewiesen werden - aus Mangel an demokratischer Substanz." (Martin Schulz, Präsident des EU-Parlamentes)-
Da die HTML-Datei vom Client nicht aus dem Web angefordert werden kann, sondern eben lokal auf einem Rechner liegt
Es oft eine spezielle Situation, in welcher irgendwas womöglich funktioniert.
Ich aber fragte hinsichtlich der Arbeit an halbwegs einfach zu verwendenden und halbwegs universellem Login-System. Und da kommt es eben nicht in Betracht, die HTML-Seite mitsamst dem Jacascript und dem öffentlichen Schlüssel auf den Rechnern der Benutzer ablegen zu wollen.
wie genau wäre Man-in-the-Middle bei einer HTTPS-Verbindung weniger "leicht" und weniger "möglich"?
Um die geht es ja nicht. Dieses CrypptoJs-Dingens sollte ein HTTPS-Ersatz sein, ist aber zu anfällig gegen relativ leichte Angriffe.
HTTPS ist dagegen geradezu sicher, jedenfalls wenn die Benutzer sich halbwegs intelligent verhalten.
Jörg Reinholz
-
wie genau wäre Man-in-the-Middle bei einer HTTPS-Verbindung weniger "leicht" und weniger "möglich"?
Naja. Bei HTTPS sind die (meisten) Schlüssel zertifiziert, also unterzeichnet und die zur Unterzeichnung berechtigenden Zertifikate sind im Browser also auf dem Rechner gespeichert. Ansonsten gäbe es da noch den Fingerabdruck, den man sich, wenn man die Schlüssel selbst erzeugt hat, auf einem Zettel notiert und andernorts beim ersten Aufruf vergleicht und dann "diese Ausnahme dauerhaft speichert".
Ansonsten steht natürlich die Frage nach:
Dem Vertrauen in die Schlüssel-Zertifikate, welches ja auch nicht immer gegeben war oder nie wieder so naiv-vollständig sein wird wie es mal war.
Dem Vertrauen in den Nutzer - von denen aber leider so mancher auf alles klickt, was wie "Ja" "Hurra" "Weiter" aussieht oder folgen der Anweisung, auf der steht:
-------------------------------------------------------------
Ohne dieses Plugin können Sie die Tütten von .... nicht sehen. Das Plugin benötigt Root-Rechte, das Recht kostenpflichtige Rufnummern anzuwählen und Ihre Position an die nächste CIA-Drohne zu übermitteln. Da sie damit einverstanden sind klicken Sie jetzt unter Beibehaltung Ihrer bisherigen Denkleistung auf "Ja", "Hurra", "Weiter"!
-------------------------------------------------------------Insgesamt aber ist es schwieriger HTTPS anzugreifen.
Jörg Reinholz
-
-
-
-