Sirke

Hallo zusammen,

Ich beobachte immer wieder, dass sich Leute Gedanken um einen sicheren Login machen, aber dabei (fast) immer einen vertraulichen Login vernachläsigen, wobei dies wohl ebenso wichtig sein sollte, wie ein sicherer Login!

Leider habe ich es bisher noch nicht geschafft Formularfelder und HTTP Digest Auth ohne JavaScipt zu verbinden! Aus diesem Grund habe ich direkt mit HTTP, JavaScipt und PHP ein Challenge Response umgesetzt, um z.B. Passwörter auf jeden Fall sicher auszutauschen und es auch erweitern zu können um Passwort geschützt Formulare abzusenden.

Dadurch kam mir die Frage: Besteht Interesse ein solches System für ein OpenSource Paket umzusetzen oder bleibt man lieber wie bisher bei "Kein SSL - keine Sicherheit!"?

Diese Umsetzung um Sicherheit zu schaffen benötigt auf jeden Fall JavaScript, weshalb mir der Gedanke kam, dass man sogar komplett vertraulichen Datenaustausch umsetzen könnte ohne TLS zu benötigen! Gleichzeitig kann man dann zudem mit Gedanken wie "Abstreitbares Surfen" spielen.

Besteht Interesse für ein solches System oder ist das viel zu viel in euren Augen?


PS: Ich bin mir nicht sicher, wie die Entwicklung im Web Sektor zur Zeit ist und XML evtl in naher Zukunft diese Lücke schließt: Daher kann jeder der dazu etwas weiß gerne seine Infos mitteilen?

Mister Ad

Flor1an

Du hast also so etwas wie den HTTP eigenen Digest Auth implementiert? Das mag für den Loginvorgang durch aus hilfreich sein. Allerdings besteht ja dann weiterhin das Problem das der Request/Response Body unverschlüsselt übertragen wird. Der men-in-the-middle kann also nicht den Usernamen und das Passwort auslesen, sieht aber trotzdem alle anderen übermittelten Daten. Ist meiner Meinung nach auch nicht viel besser! Möchte der User sein Passwort ändern, hast du ein Problem. Denn ein neues Passwort lässt sich mit dieser Methode nicht übertragen!

Von daher führt imho kein Weg ab HTTPS/SSL vorbei. Und das wirkt auch nur dann wenn das Zertifikat von einer CA signiert wurde die dem Benutzer bekannt ist! Alles andere wäre trügerische (Un-)Sicherheit.

Wie hast du dir das genau vorgestellt? Ein PKI Verfahren fällt weg. Symmetrische Verschlüsselung sehe ich auch als Problem an denn dann müsstest du die Passwörter der Benutzer im Klartext (bzw. entschlüsselbar) abspeichern was auch keine gute Lösung ist.

Und inwieweit soll XML diese Lücke schließen? Kann mir grad nicht vorstellen wie XML da helfen soll.

Sirke

Ja, genau und sehe ich auch so!

Ich denke auch das diese beiden Punkte etwas zu unterscheiden sind, weil Passwörter eine andere Stufe der Vertraulichkeit benötigen als "bloße" Daten/Informationen. Möchte man komplett vertrauliches Surfen wäre diese Methode sicherlich nicht sinnvoll!

Ein Verändern des Passwortes kann man schon schützen, da dem Server das alte bekannt ist! Ein erstes neues Passwort hingegen muss über einen sicheren Kanal übertragen werden, wozu man einmalig asymm Krypto nutzen könnte.

Ich habe mir gedacht asymm Krypto zum Aufsetzen einer Session zu nutzen und anschließend symm Krypto zu nutzen und neuen Content mit AJAX nachzuladen. Damit würde natürlich Tabbing nicht möglich sein, aber ist ja auch erstmal nicht zwingend gewollt!

Ich meine XML nicht als reine Sprache, sondern die Entwicklung der Frameworks! Eine Implementierung von XML Security in Webbrowser und eine Kompatibilität zu XHTML könnte schnell diese Unsicherheits-Lücke schließen, indem man nicht auf der Transportschicht verschlüsselt, sondern auf der Anwendungsschicht! Sofern dies für eine nahe Zukunft vorgesehen wäre, würde das eine Reihe von Problemen lösen...

Flor1an

Wie möchtest du denn ein asymmetrisches Verfahren implementieren? Stell ich mir mit JS sehr schwer vor. Du musst schließlich den öffentlichen Schlüssel des Partners "überprüfen". Dafür brauchst du eine Zertifikathierarchie und das wirst du mit JS nicht realisieren können.

Dann wäre vielleicht eher ein Schlüsselaustausch über Diffie Hellman interessant. Aber ehrlich gesagt stell ich mir das recht kompliziert vor. Grad wenn du dann alles mit JS und AJAX laufen lassen musst.

In Sachen XML ist mir persönlich jetzt nichts bekannt.

Beitrag editiert:
Bei einem Mitm der Nachrichten manipulieren kann ist DH natürlich auch nicht sicher. War doch kein guter Einfall

Sirke

Ich habe extra von asymm Krypto gesprochen, welche nicht zwingend eine PKI erfordert und elliptische Kurven haben auch in JS eine akzeptable Geschwindigkeit!

Ein DH ist nur unsicher, wenn man kein Authentifikationsmerkmal hat, aber Server und Benutzer haben beide Kenntnis vom Passwort! Jedoch wäre dann ein symm Schlüsselaustausch sinniger, weil schneller...


Das Interesse scheint ja nicht sooo groß zu sein...

Flor1an

Ich denke das liegt daran dass es halt zum einen problematisch und zum anderen umständlich ist. Hier tummeln sich auch vor allem Anfänger die noch nicht so tief ins Thema Sicherheit eingestiegen sind. Von daher fehlt wohl zum einen das Wissen und auch die Notwendigkeit.

Und bei "Profis" wird dann halt auf SSL gesetzt.

Wenn der Server das Passwort vom User kennt finde ich das aber auch problematisch. Denn ich möchte eigentlich nicht das meine Passwörter im Klartext gespeichert werden und sich der Betreiber jeder Zeit beliebige Passwörter auslesen kann oder bei einer SQL Injection alle Passwörter bekannt werden. Von daher sollte nur der salted hash abgespeichert werden, dann fehlt aber wieder ein gemeinsames Geheimnis dass man für Verschlüsselung nutzen könnte.

Sirke

Das ist natürlich verständlich, wobei ich gehofft hatte, dass man evtl mit den etwas erfahreneren Benutzern dann vllt sprechen kann oder auch unerfahrene Interesse daran zeigen?!

Zu dem Passwort noch kurz: Der Benutzer kann den Salted Hash bilden, sobald er das Salz kennt, sodass eine Passwortabfrage dann eine Runde mehr benötigen würde!


Das Thema kann dann geschlossen werden!

Flor1an

Mh das stimmt natürlich, ich kann auf Clientseite den Hash bilden und das als gemeinsames Passwort nutzen. Das wäre dann schon mal ne Grundlage auf der man arbeiten könnte.

Den Thread kannst du als erledigt markieren. Schließen müssen wir ihn ja nicht, vlt. will ja noch wer was dazu sagen.