Passwörter übertragen

[Y0Gi]

Was aktuelles: http://www.heise.de/newsticker/meldung/99318

Auch der Einsatz von Verschlüsselung hilft bei Nachlässigkeit des Anwenders nicht unbedingt weiter. So berichtet das Teamfurry-Blog von einem Exit-Node in Deutschland, der offenbar versucht, sich per Man-in-the-Middle-Attacke in SSL-Verbindungen einzuschleichen. Dazu lieferte er bei über ihn laufende SSL-Verbindungen ein gefälschtes, respektive selbstunterschriebenes Zertifikat aus. Das produziert zwar in der Regel eine Fehlermeldung, oftmals ignorieren Anwender diese jedoch.

[veers]

Was aktuelles: http://www.heise.de/newsticker/meldung/99318

Auch der Einsatz von Verschlüsselung hilft bei Nachlässigkeit des Anwenders nicht unbedingt weiter. So berichtet das Teamfurry-Blog von einem Exit-Node in Deutschland, der offenbar versucht, sich per Man-in-the-Middle-Attacke in SSL-Verbindungen einzuschleichen. Dazu lieferte er bei über ihn laufende SSL-Verbindungen ein gefälschtes, respektive selbstunterschriebenes Zertifikat aus. Das produziert zwar in der Regel eine Fehlermeldung, oftmals ignorieren Anwender diese jedoch.

Falls du das gerne selber mal ausprobieren willst, ettercap kann das Wobei das in Deutschland jetzt wohl ein verbotenes Terroristenwerkzeug ist.

[Y0Gi]

Jop, ettercap gutmütig zu umschreiben ist schon nicht ganz einfach Zu Telnet-Zeiten gab's dafür Juggernaut.

[Bodyslam]

Hallo Zusammen,

ich bin gerade dabei mich zu informieren zum Thema sicherer Login. Nun ist das Thema ja ziemlich groß und ich denke an eine gute Umsetzung per https. Ist es denn mit https nun tatsächlich so einfach Daten sicher zu übertragen? Wenn die Daten so oder so verschlüssel übertragen werden, dann könnte man (was ich nie machen würde) PW auch im Klartext übertragen.Https nimmt einem durch seine hauseigene Verschlüsselung doch ziemlich viel Programmierarbeit ab.

Nachdem ich hier im Forum schon einiges gelesen habe, würde ich ohne https ein Login gar nicht gestalten, da der Aufwand einer sicheren Übertragung ohne viel zu groß ist, daher meine Frage: würde es mit der Verschlüsselung durch https ausreichen, ein Login (cookies und sessions obligatorisch) so zu gestalten, dass der Hashwert des PW zusammen mit dem Namen übertragen wird?

MfK
B.

[BlackJack]

@Bodyslam: Ob Du nun ein Passwort oder dessen Hashwert überträgst ist eigentlich egal, denn wenn der Server immer nur den Hashwert bekommt, dann ist das aus seiner Sicht ein Passwort, also überträgst Du wieder ein Passwort. HTTPS ist so sicher wie die Zertifikate die dafür verwendet werden und ob der Anwender aufpasst, dass auch das richtige Zertifikat verwendet wird. Also beim 08/15-Anwender ist das nicht sicher. Aber für viele Sachen halt sicher genug.

[Sirius3]

@BlackJack: wenn Du einen richtig gesalzenen Hash des Passwortes überträgst [eigentlich hash(salz2+hash(salz1+passwort))] dann hat man tatsächlich Einmalpasswörter die nicht wiederverwendet werden können.

[Bodyslam]

Für mich ist momentan die Frage wie ich ein ordentlichen Login implementiere, sessions und cookies verwalten ja letzendlich nur bestehende Daten, also ist für mich die Frage wie bekomme ich eine Anmeldung so hin, dass sie "sicher" ist. Ich habe jetzt hier viele Themen gelesen, davon wie es jens, DefNull, Gerold sehen, aber wie bekomme ich ein PW von Browser zum Server( und bei einer Anmeldung zurück, wobei dass dann wohl wieder etwas anderes ist). Gibt es da ein Modul, oder weiss vielleich jmd ob es da etwas bei Cherrypy gibt, was ich übersehen habe? Eine dynamische Seite ohne ordentliche Userverwaltung ist meiner Ansicht nach sinnlos.

[BlackJack]

@Sirius3: Das macht die Sache aber nur ein bisschen komplizierter. Voraussetzung ist ja wir vertrauen HTTPS nicht weil sich da jemand dazwischen schalten könnte. Das heisst der JavaScript-Code, der das eingegebene Passwort beim Client verarbeitet, ist auch nicht vertrauenswürdig. Ich denke vom praktischen Standpunkt vertraut man HTTPS, und dem Anwender ein wenig Hirnschmalz zu, oder man kann es vergessen.

[Sirius3]

@BlackJack: Beim Salzen vertraue ich ja gerade nicht auf den Client-Code, sondern der Server überprüft, ob schon jemand anderes versucht hat, sich mit der selben Session einzuloggen. Das heißt also, finde ich irgendwo einen gesalzenes Passwort kann ich damit nichts anfangen. Dass ich direkt am Client das Passwort (u.U. mit Hilfe eines Keyloggers) abgreifen kann, dagegen gibt es kein Mittel.

[BlackJack]

@Sirius3: Das verstehe ich jetzt nicht? Der Man in the middle kann doch das Klartextpasswort abgreifen und aus Sicht des Servers alles machen was der erwartet.

[Leonidas]

Ich würde, wenn ich die Cookies setze noch weitere Attribute wie secure (damit das Cookie nicht aus versehen über HTTP läuft) sowie HttpOnly setzen.