[Metalab] Jublogin

[Paul Böhm]

On 6/2/07, Johannes Buchner <buchner.johannes at 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