Passwörter übertragen

[JanDMC]

Hallo Leute,

Wie übertrag ich am besten Passwörter, die dann in einer DB(SQLite3) gespeichert werden. Ich benutze Sockets. Der Client sendet das Passwort and den Server , der dann in der DB nachguckt ob das richtig ist.

mfg
Jan

[sma]

Hi,

ich würde empfehlen, niemals Kennworte direkt zu übermitteln. Besser ist es, eine sogenannten kryptografische Hash-Funktion (z.B. MD5 oder SHA1) auf das Kennwort anzuwenden, das Ergebnis zu verschicken und auf der Serverseite das Originalkennwort ebenfalls mit der selben Hash-Funktion zu behandeln und dann die Ergebnisse zu vergleichen.

Die besondere Eigenschaft einer kryptografischen Hash-Funktion ist, dass sie nur in eine Richtung funktioniert, d.h. du kannst zwar einen String S damit zu einem S' machen, aber aus S' nicht wieder zurück auf S schließen.

Es ist auch eine gute Idee, niemals Kennworte im Klartext in einer Datenbank abzulegen - schon um nicht den Datenbank-Administrator in Versuchung zu führen.

Stefan

[veers]

Verwende SSL/TLS

[rayo]

ich würde empfehlen, niemals Kennworte direkt zu übermitteln. Besser ist es, eine sogenannten kryptografische Hash-Funktion (z.B. MD5 oder SHA1) auf das Kennwort anzuwenden, das Ergebnis zu verschicken und auf der Serverseite das Originalkennwort ebenfalls mit der selben Hash-Funktion zu behandeln und dann die Ergebnisse zu vergleichen.

Das bringt leider nicht wirklich viel Übertragungssicherheit dazu, da kann jemand der das abhört genau gleich S' an den Serve rschicken und schon ist er authentifiziert.

Gruss

[nemomuk]

ich würde dir empfehlen das ganze über https zu machen, dann hast du von Hause aus eine Verschlüsselung oder Clientseitig per Javascript das Passwort verschlüsseln, nur was ist, wenn jemand kein JScript aktiviert hat?

[veers]

ich würde dir empfehlen das ganze über https zu machen, dann hast du von Hause aus eine Verschlüsselung oder Clientseitig per Javascript das Passwort verschlüsseln, nur was ist, wenn jemand kein JScript aktiviert hat?

Er arbeitet mit Sockets. Daraus schliesse ich mal das weder HTTP noch Javascript verwendet werden.

Gruss,
Jonas

[gerold]

Wie übertrag ich am besten Passwörter, die dann in einer DB(SQLite3) gespeichert werden. Ich benutze Sockets.

Hallo Jan!

Wenn du nicht die Passwörter, sondern den MD5-Hash in der Datenbank speicherst, dann hast du den Vorteil, dass die realen Passwörter deiner Kunden nicht verloren sind, wenn jemand Zugriff auf deine SQLiteDB bekommt.

Der Server vergleicht dann nur noch den frisch erzeugten MD5-Hash mit dem in der DB gespeicherten MD5-Hash. Beim Verbinden wird weiterhin das Klartextpasswort übertragen. Also könnte dieses immer noch abgehorcht werden.

Aber das kannst du verhindern, indem du den gesamten Datenverkehr verschlüsselst. Also nicht nur die Übertragung der Passwörter, sondern die komplette Verbindung.

Dafür gibt es erprobte Produkte. Z.B. SSH (Portumleitung), PPTP, oder mein Liebling: OpenVPN

Damit bist du auf der sicheren Seite, ohne dass du dich in deinem Programm selber darum kümmern musst.

mfg
Gerold

[Y0Gi]

Klar, reine Übertragungen selbst von gehashten Passwörtern sind natürlich noch für Replay-Attacken anfällig. Dies lässt sich durch Challenge-Response-Verfahren umgehen.

Letztlich ist SSL/TLS aber eine bewährte Lösung, die sich ohne das Schreiben einer eigenen Implementierung nutzen lässt.

[veers]

Klar, reine Übertragungen selbst von gehashten Passwörtern sind natürlich noch für Replay-Attacken anfällig. Dies lässt sich durch Challenge-Response-Verfahren umgehen..

Welches sich dann wieder mit einem "Man in the middle" Angriff aushebeln lässt.

Zum selber schreiben: Wenn ich sehe wie viele Problem richtig erfahrene Personen beim Design und bei der Implementierung von SSL hatten halte ich das nur in sehr wenigen Fällen für eine gute Idee.

[Y0Gi]

Klar, reine Übertragungen selbst von gehashten Passwörtern sind natürlich noch für Replay-Attacken anfällig. Dies lässt sich durch Challenge-Response-Verfahren umgehen..

Welches sich dann wieder mit einem "Man in the middle" Angriff aushebeln lässt.

Ebenso wie SSL

[veers]

Klar, reine Übertragungen selbst von gehashten Passwörtern sind natürlich noch für Replay-Attacken anfällig. Dies lässt sich durch Challenge-Response-Verfahren umgehen..

Welches sich dann wieder mit einem "Man in the middle" Angriff aushebeln lässt.

Ebenso wie SSL

Zeigst du mir mal wie du eine SSL Verbindung mit Zertifikats Validierung mit einem Man in the Middle aushebelst?

[Y0Gi]

Der Schwachpunkt ist wie so oft der User, der Zertifikate nicht exakt validieren kann oder will. U.a. in der hakin9 war dazu mal ein interessanter Artikel, der sich auf SSL-gesicherte Jabber-Verbindungen bezog.

In diesem Fall wird die Validierung jedoch vorzugsweise automatisch vorgenommen, nehme ich mal stark an. Wenn ich mich recht entsinne, lassen sich allerdings auch Zertifikate unterschieben, die über Kollisionsfindung den selben Fingerprint haben (und andere Daten, doch die müssen dafür auch erstmal überprüft werden).

[veers]

Mit dem Benutzer hast du recht. Aber da lässt sich nicht viel machen.

TLS verwendet afaik SHA1+MD5 für die Signaturen. Da dürfte es schwierig sein einen preimage Angriff auszuführen. Selbst wenn nur MD5 verwendet wird dürfte ein preimage Angriff noch sehr schwierig sein.

[Y0Gi]

Aber nicht unmöglich Letztlich sind hier einige Lösungen genannt worden, die für die Zwecke schon eine gute Basis sind und um Längen besser als unverschlüsselte oder nur gehashte Passwortübermittlung.

Fraglich ist auch die Umgebung des Systems: Begrenztes LAN oder Internet? Bei letzterem kann man auch einen VPN-Tunnel in Erwägung ziehen.

[Leonidas]

In einem LAN könnte man auch IPSec oder gleich IPv6 + zugehörige Sicherheitstechnik einsetzen.

[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.