Hallo liebe Labber! Ich möchte kurz jublogin vorstellen, und euch fragen, was ihr davon haltet: http://jublogin.sourceforge.net/ Es implementiert eine CHAP-ähnliche Authentifizierung für Web-Logins, um Abhören und Replay-Attacken unmöglich zu machen. Genauere technische Details: http://jublogin.sourceforge.net/types Demos: http://jublogin.sourceforge.net/demos 1) Seht ihr irgendwelche groben Probleme, Fehler, die ich gemacht habe? 2) Haltet ihr das für sinnvoll, wert, in andere Anwendungen einzubauen (z.B. diverse CMS, online-banking) 3) Sonstige Kommentare, Bashing, Troll-posts, flames :-) Liebe Grüße, Johannes Buchner
Also das is verschlüsselung nur für passwörter wennst kein HTTPS verfügbar hast? wtf? srsly? Wir ham eh grad drüber gredet, also... äh... ich seh irgendwie keinen use case. Wennst sicherheit willst, willst eh HTTPS. User die auf Phishing reinfallen, sind so auch nicht geschützt. Der einzige Schutz wäre gegen man-in-the-middle zeugs, aber... ja... äh... dann gleich richtig (tunneln/https). Und Banken... verwenden sowieso HTTPS. ;) On 6/2/07, Johannes Buchner <buchner.johannes@gmx.at> wrote:
Hallo liebe Labber!
Ich möchte kurz jublogin vorstellen, und euch fragen, was ihr davon haltet:
http://jublogin.sourceforge.net/
Es implementiert eine CHAP-ähnliche Authentifizierung für Web-Logins, um Abhören und Replay-Attacken unmöglich zu machen.
Genauere technische Details: http://jublogin.sourceforge.net/types Demos: http://jublogin.sourceforge.net/demos
1) Seht ihr irgendwelche groben Probleme, Fehler, die ich gemacht habe? 2) Haltet ihr das für sinnvoll, wert, in andere Anwendungen einzubauen (z.B. diverse CMS, online-banking) 3) Sonstige Kommentare, Bashing, Troll-posts, flames :-)
Liebe Grüße, Johannes Buchner
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at http://lists.metalab.at/mailman/listinfo/metalab
wenn jemand das passwort mitlesen könnte wenns plaintext ist, aber das passwort irgendwie gesichert wird, bringt das nur der sicherheit des passworts was. dein verfahren scheint allerdings weit weit von zero knowledge proofs oder so entfernt zu sein, und daher ist selbst der nutzen für die passwort sicherheit sehr fraglich. replay attacken auf die authentifikation sind in dem fall übrigens uninteressant die tcp verbindung ist immer noch MITM hijackbar (z.B. bei connection basierter authentifikation), und die session id ist sowieso ungeschützt (bei normalem stateless http) authentifizierung bringt dir nichts ohne integrität der daten die du im nachhinein überträgst. https versucht dir integrity und confidentiality im bündel-paket zu geben - viel besseres ist bisher leider niemandem eingefallen. integrity ohne confidentiality wäre auch nicht billiger. zu dem thema vielleicht auch mal NTLM und digest authentication, und deren probleme ansehen: http://www.innovation.ch/personal/ronald/ntlm.html http://www.ietf.org/rfc/rfc2617.txt lg paul On 6/2/07, Florian Hufsky <florian.hufsky@gmail.com> wrote:
Also das is verschlüsselung nur für passwörter wennst kein HTTPS verfügbar hast? wtf? srsly?
Wir ham eh grad drüber gredet, also... äh... ich seh irgendwie keinen use case. Wennst sicherheit willst, willst eh HTTPS. User die auf Phishing reinfallen, sind so auch nicht geschützt. Der einzige Schutz wäre gegen man-in-the-middle zeugs, aber... ja... äh... dann gleich richtig (tunneln/https).
Und Banken... verwenden sowieso HTTPS.
;)
On 6/2/07, Johannes Buchner <buchner.johannes@gmx.at> wrote:
Hallo liebe Labber!
Ich möchte kurz jublogin vorstellen, und euch fragen, was ihr davon haltet:
http://jublogin.sourceforge.net/
Es implementiert eine CHAP-ähnliche Authentifizierung für Web-Logins, um Abhören und Replay-Attacken unmöglich zu machen.
Genauere technische Details: http://jublogin.sourceforge.net/types Demos: http://jublogin.sourceforge.net/demos
1) Seht ihr irgendwelche groben Probleme, Fehler, die ich gemacht habe? 2) Haltet ihr das für sinnvoll, wert, in andere Anwendungen einzubauen (z.B. diverse CMS, online-banking) 3) Sonstige Kommentare, Bashing, Troll-posts, flames :-)
Liebe Grüße, Johannes Buchner
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at http://lists.metalab.at/mailman/listinfo/metalab
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at http://lists.metalab.at/mailman/listinfo/metalab
Danke für die ersten Postings! Klar, HTTPS verwenden, bin ich voll dafür. Möchte ich auch nicht ersetzen. True, ich kann als MITM-Attacker die Session steuern. Aber mein Passwort weiß der Angreifer nicht. Und wenn die Session beendet ist, kann er keine neue beginnen (er kann sie aufrechterhalten versuchen). Und ich kann auf jedem Account das gleiche Passwort verwenden, ohne dass irgendwer davon was weiß. Du hast recht Paul, die Daten schütze ich nicht damit, dass ist auch nicht das Ziel. Aber das Passwort. Richtig, ich könnte digest-auth verwenden. Aber das is sooo hässlich ;-) Und was ist, wenn ich 3 Login-Felder hab: Kategorie, Name, Password? Idealerweise nimmt man HTTPS und wrappt es drüber. Manchmal hat man dazu aber nicht die Möglichkeit. Jublogin soll jetzt auch nicht _die_ Erleuchtung in Web-Security sein, sondern nur einen Schliff Formular-Logins für den User (bzw. sein Passwort) verbessern. Und wenns das nicht ist, dann hab ich zumindest ein schönes Dokuwiki-Template für die Webseite geschrieben ;-) lg, Johannes On Saturday, 2. June 2007 16:42:52 Paul Böhm wrote:
wenn jemand das passwort mitlesen könnte wenns plaintext ist, aber das passwort irgendwie gesichert wird, bringt das nur der sicherheit des passworts was. dein verfahren scheint allerdings weit weit von zero knowledge proofs oder so entfernt zu sein, und daher ist selbst der nutzen für die passwort sicherheit sehr fraglich.
replay attacken auf die authentifikation sind in dem fall übrigens uninteressant die tcp verbindung ist immer noch MITM hijackbar (z.B. bei connection basierter authentifikation), und die session id ist sowieso ungeschützt (bei normalem stateless http)
authentifizierung bringt dir nichts ohne integrität der daten die du im nachhinein überträgst.
https versucht dir integrity und confidentiality im bündel-paket zu geben - viel besseres ist bisher leider niemandem eingefallen. integrity ohne confidentiality wäre auch nicht billiger.
zu dem thema vielleicht auch mal NTLM und digest authentication, und deren probleme ansehen: http://www.innovation.ch/personal/ronald/ntlm.html http://www.ietf.org/rfc/rfc2617.txt
lg paul
On 6/2/07, Florian Hufsky <florian.hufsky@gmail.com> wrote:
Also das is verschlüsselung nur für passwörter wennst kein HTTPS verfügbar hast? wtf? srsly?
Wir ham eh grad drüber gredet, also... äh... ich seh irgendwie keinen use case. Wennst sicherheit willst, willst eh HTTPS. User die auf Phishing reinfallen, sind so auch nicht geschützt. Der einzige Schutz wäre gegen man-in-the-middle zeugs, aber... ja... äh... dann gleich richtig (tunneln/https).
Und Banken... verwenden sowieso HTTPS.
;)
On 6/2/07, Johannes Buchner <buchner.johannes@gmx.at> wrote:
Hallo liebe Labber!
Ich möchte kurz jublogin vorstellen, und euch fragen, was ihr davon haltet:
http://jublogin.sourceforge.net/
Es implementiert eine CHAP-ähnliche Authentifizierung für Web-Logins, um Abhören und Replay-Attacken unmöglich zu machen.
Genauere technische Details: http://jublogin.sourceforge.net/types Demos: http://jublogin.sourceforge.net/demos
1) Seht ihr irgendwelche groben Probleme, Fehler, die ich gemacht habe? 2) Haltet ihr das für sinnvoll, wert, in andere Anwendungen einzubauen (z.B. diverse CMS, online-banking) 3) Sonstige Kommentare, Bashing, Troll-posts, flames :-)
Liebe Grüße, Johannes Buchner
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at http://lists.metalab.at/mailman/listinfo/metalab
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at http://lists.metalab.at/mailman/listinfo/metalab
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at http://lists.metalab.at/mailman/listinfo/metalab
On 6/2/07, Johannes Buchner <buchner.johannes@gmx.at> wrote:
Klar, HTTPS verwenden, bin ich voll dafür. Möchte ich auch nicht ersetzen. True, ich kann als MITM-Attacker die Session steuern. Aber mein Passwort weiß der Angreifer nicht. Und wenn die Session beendet ist, kann er keine neue beginnen (er kann sie aufrechterhalten versuchen).
dh. damit ist die seite bei der du dich gerade anmelden wolltest bereits für den angreifer zugänglich
Und ich kann auf jedem Account das gleiche Passwort verwenden, ohne dass irgendwer davon was weiß.
1) die seite weiss davon, ausser du tust beim setzten bereits mit nem salt hashen - und selbst dann kann man mangels fehlender integrität das passwort immer noch mitschicken lassen 2) ok, admitted, ein angreifer kann ob der challenge nicht das passwort nehmen und zur nächsten seite gehen. aber er kann dir auf seite A die selbe challenge geben, wie er sie gerade bei seite B braucht
Du hast recht Paul, die Daten schütze ich nicht damit, dass ist auch nicht das Ziel. Aber das Passwort.
das passwort ist der seite bekannt. das ist der schlimmste faktor bei password reuse
Richtig, ich könnte digest-auth verwenden. Aber das is sooo hässlich ;-) Und was ist, wenn ich 3 Login-Felder hab: Kategorie, Name, Password?
niemand benutzt digest - zu inflexibel.. aber aus den problemen von digest kann man lernen ;)
Idealerweise nimmt man HTTPS und wrappt es drüber. Manchmal hat man dazu aber nicht die Möglichkeit.
die möglichkeit nicht zu haben ist wahnwitz
Jublogin soll jetzt auch nicht _die_ Erleuchtung in Web-Security sein, sondern nur einen Schliff Formular-Logins für den User (bzw. sein Passwort) verbessern.
z.B. gmail macht folgendes: auth über https, restliche verbindung ohne https (ausser man erzwingt https mit greasemonkey oder so). hat fast den gleichen effekt wie das was du machst
Und wenns das nicht ist, dann hab ich zumindest ein schönes Dokuwiki-Template für die Webseite geschrieben ;-)
naja, vielleicht bringts ja sogar ein klein wenig was, wenn die seite das passwort nicht weiss allerdings ist das halt leider jederzeit deaktivierbar, da der angreifer ja einfach das übermittelte javascript impotent machen kann (z.B. das plaintext passwort in nem unverwendeten feld mitschicken) den letzten versuch in die richtung hab ich übrigens hier gesehen: http://www.angel.net/~nic/passwd.html rennt rein clientseitig, und gibt dem user daher mehr kontrolle ich selbst bin inzwischen dazu übergegangen einen mit einem master password geschützten password-vault zu benutzen, und versuch mir gerade anzugewöhnen überall verschiedene passwörter einzusetzen. lg paul
On Saturday, 2. June 2007 21:14:07 Paul Böhm wrote:
On 6/2/07, Johannes Buchner <buchner.johannes@gmx.at> wrote:
Klar, HTTPS verwenden, bin ich voll dafür. Möchte ich auch nicht ersetzen. True, ich kann als MITM-Attacker die Session steuern. Aber mein Passwort weiß der Angreifer nicht. Und wenn die Session beendet ist, kann er keine neue beginnen (er kann sie aufrechterhalten versuchen).
dh. damit ist die seite bei der du dich gerade anmelden wolltest bereits für den angreifer zugänglich Jap.
Und ich kann auf jedem Account das gleiche Passwort verwenden, ohne dass irgendwer davon was weiß.
1) die seite weiss davon, ausser du tust beim setzten bereits mit nem salt hashen - und selbst dann kann man mangels fehlender integrität das passwort immer noch mitschicken lassen Am Client nicht hashen, aber am Datenbank-server hashed passwords verwenden, am besten salted.
2) ok, admitted, ein angreifer kann ob der challenge nicht das passwort nehmen und zur nächsten seite gehen. aber er kann dir auf seite A die selbe challenge geben, wie er sie gerade bei seite B braucht True. Vielleicht könnte man mit einem Handshake (XMLHttpRequest) das ID-Handshake verbessern, so dass sich keiner der zwei die ID alleine aussuchen kann (z.B. ala RSA).
Du hast recht Paul, die Daten schütze ich nicht damit, dass ist auch nicht das Ziel. Aber das Passwort.
das passwort ist der seite bekannt. das ist der schlimmste faktor bei password reuse Nicht bei (salted) hashed passwords in der DB.
Richtig, ich könnte digest-auth verwenden. Aber das is sooo hässlich ;-) Und was ist, wenn ich 3 Login-Felder hab: Kategorie, Name, Password?
niemand benutzt digest - zu inflexibel.. aber aus den problemen von digest kann man lernen ;) Ja, alle Probleme von digest mit challenges erbt jublogin. Außer vielleicht dass es nicht hässlich ist/sein muss und dass es flexibler ist.
Idealerweise nimmt man HTTPS und wrappt es drüber. Manchmal hat man dazu aber nicht die Möglichkeit.
die möglichkeit nicht zu haben ist wahnwitz
Jublogin soll jetzt auch nicht _die_ Erleuchtung in Web-Security sein, sondern nur einen Schliff Formular-Logins für den User (bzw. sein Passwort) verbessern.
z.B. gmail macht folgendes: auth über https, restliche verbindung ohne https (ausser man erzwingt https mit greasemonkey oder so). hat fast den gleichen effekt wie das was du machst Ja, da wird das Login auch in einem Iframe geladen, was ich ziemlich cool find, weil man nicht ewig auf die Seite warten muss wenn das Passwort falsch war.
Und wenns das nicht ist, dann hab ich zumindest ein schönes Dokuwiki-Template für die Webseite geschrieben ;-)
naja, vielleicht bringts ja sogar ein klein wenig was, wenn die seite das passwort nicht weiss s.o. bei 1)
allerdings ist das halt leider jederzeit deaktivierbar, da der angreifer ja einfach das übermittelte javascript impotent machen kann (z.B. das plaintext passwort in nem unverwendeten feld mitschicken) Ja, deswegen hab ich angedacht, dass man z.B. eine Firefox-Extension schreiben könnte, damit der Source nicht mehr in der Webseite ist. Aber naja.
den letzten versuch in die richtung hab ich übrigens hier gesehen: http://www.angel.net/~nic/passwd.html
rennt rein clientseitig, und gibt dem user daher mehr kontrolle
ich selbst bin inzwischen dazu übergegangen einen mit einem master password geschützten password-vault zu benutzen, und versuch mir gerade anzugewöhnen überall verschiedene passwörter einzusetzen. Tja. Dann crasht dein OS und du weißt alle deine PW nimmer ... oder du willst mehrere verschiedene Betriebssysteme verwenden ... musst immer synchronisieren. Ich bin von den Passwortmanagern nicht so begeistert ... geht das nicht am Sinn von Passwörtern vorbei (Something the user knows) wenn man sich immer was anderes einfallen lässt?
lg, Johannes
Teilnehmer (3)
-
Florian Hufsky -
Johannes Buchner -
Paul Böhm