D.h. der Server darf ruhig loggen was er mag.

Und wenn das Passwort doch klartext übertragen wird, dann ist wohl eher DAS das Sicherheitsproblem und nicht irgendein Log am Server.

OK, eine Ausnahme die mir jetzt einfällt: wenn man eine Verbindung mit z.B. SSL gesichert hat (und mal davon ausgeht dass da dann wirklich keiner mehr "mithorchen" kann), und über diese gesicherte Verbindung dann das Passwort schickt, so dass es nach dem "entschlüsseln" man anderen Ende wieder Klartext rauskommt, dann kann zwar keiner mehr mithören, das von dir erwähnte Problem ergibt sich aber trotzdem.

Kannst du mal sagen an welchen konkreten Fall du gedacht hast?

Übrigens würde mich mal interressieren bei wie vielen Registrierten er mit dem Forumpasswort sich bei der hinterlegten E-Mail-Adresse einloggen könnte

Würde mich auch nicht wundern wenn bei den meisten Foren das Passwort sowieso im Klartext in der Datenbank stünde...

Von daher...

Würde mich interessieren wie meistgenutzen Foren (phpbb etc.) da abschneiden, also was Sicherheit angeht.
Über JavaScript z.B. liesse sich da ja durchaus einiges machen.

Allerdings wäre es vermutlich einfacher gleich die normale HTTP Authentifizierung zu verwenden, bloss dass das die wenigsten Foren tun. OK, mit dem IIS ist HTTP Authentifizierung lästig, bloss die meisten Foren laufen sowieso auf Linux Servern.

Allerdings ist es mir neu, dass falsche Eingaben mitgeloggt werden. Bringt ja nichts. Der Webmaster braucht ja das Passwort nicht und wenn er es doch wissen will dann hat er deutlich einfachere Möglichkeiten als sich auf falsch geschriebene Passwörter zu stürzen.

Von einer clientseitigen Hash-Methode hab ich auch noch nicht mitbekommen... was aber anhand der Manipulationsmöglichkeiten auch selten sinnvoll wäre

Würde mich auch nicht wundern wenn bei den meisten Foren das Passwort sowieso im Klartext in der Datenbank stünde...

Uh. Nein. Würde mich sogar eher wundern, wenn das je üblich gewesen wäre, mag sein, dass die Qualität der Hashverfahren variiert, aber das wäre ja wohl der absolute Security-GAU.

Allerdings ist es mir neu, dass falsche Eingaben mitgeloggt werden. Bringt ja nichts.

Exakt, wüsste nicht so recht, wozu man das machen sollte, selbst zu Debugging-Zwecken ist das nur wenig hilfreich.

Der Webmaster braucht ja das Passwort nicht und wenn er es doch wissen will dann hat er deutlich einfachere Möglichkeiten als sich auf falsch geschriebene Passwörter zu stürzen.

Stimmt.

hustbaer schrieb:

Würde mich auch nicht wundern wenn bei den meisten Foren das Passwort sowieso im Klartext in der Datenbank stünde...

Uh. Nein. Würde mich sogar eher wundern, wenn das je üblich gewesen wäre, mag sein, dass die Qualität der Hashverfahren variiert, aber das wäre ja wohl der absolute Security-GAU.

OK, hab gerade bei phpBB nachgesehen, die verwenden wohl MD5
Was Lösungen Marke Eigenbau angeht bin ich mir allerdings immer noch ziemlich sicher dass da viele das Passwort cleartext speichern. Angesichts der miesen Passwörter die Leute verwenden allerdings auch ziemlich egal. OK, ein salted hash bringt einiges, wenn das salt ausreichend gut geheim gehalten wird.

@zwutz:

Von einer clientseitigen Hash-Methode hab ich auch noch nicht mitbekommen... was aber anhand der Manipulationsmöglichkeiten auch selten sinnvoll wäre

Naja, zumindest bin ich mal nicht der einzige der auf die Idee gekommen ist
http://krahulg.wordpress.com/2007/12/26/preparing-a-secure-login-form-with-php-javascript/

Wie auch immer, ideal wäre IMO HTTP Login + HTTPS.

Für mich ist es auf jeden Fall irgendwie erschreckend dass so wenig Seiten HTTPS Login verwenden. Oder anders rum: dass so viele Seiten cleartext Passwörter über unverschlüsselte HTTP Verbindungen schicken.