Entwickler-Ecke
Sonstiges (Web-Entwicklung) - Passwort sicher senden
matze - Mi 18.07.07 16:00
Titel: Passwort sicher senden
Hallo.
Ich habe ein ganz simples Login Formular, in dem Benutzername und Passwort abgefragt wird. Wenn das der User abschickt, wird das Passwort ja im Klartext übertragen, sprich wenn einer mit nem Packetsniffer oder nem Proxy lauscht, dann kommt er an das Passwort ran.
Meine Frage: Ist das besser, wenn ich die Authentifizierung via HTTP Header mache oder gibt es Möglichkeiten das Passwort am Client vor dem Senden verschlüsseln zu lassen?
Danke für die Hilfe,
Matze
mkinzler - Mi 18.07.07 16:05
-SSl
-ein Senden des Passwortes kann durch Hashen und Übertragen dessen umgangen werden.
matze - Mi 18.07.07 16:55
SSL gfällt leider aus. Das unterstützt der Zielserver leider nicht. Habe ich vergessen zu schrieben.
Wie kann ich denn Clientseitig das Passwort hashen und das dann senden? Vermutlich mit JavaScript, oder? Hat da jemand einen Codeschnipsel, mit dem man das macht?
Christian V. - Mi 18.07.07 18:15
Und was wenn der Browser kein JS untersützt, bzw deaktiviert hat?
r2c2 - Mi 18.07.07 18:37
 mkinzler hat folgendes geschrieben: |
-ein Senden des Passwortes kann durch Hashen und Übertragen dessen umgangen werden. |
Bringt aber nix. Dann sniff ich eben den Hash mit und schick den über n schnell zusammengebasteltes html-File oder zur Not über Indy an dich und bin auch drin...
mfg
Christian
Chryzler - Mi 18.07.07 18:55
Keine Ahnung ob das in PHP umsetzbar ist oder nicht (ich denke mal schon): Der Server gibt dir den zu verwendeten Salt vor:
1. Server schickt zufälligen Salt zum Client, je länger desto sicherer, wobei eigentlich 8-16 Bytes locker reichen müssten
2. Client berechnet Hash von Salt + Passwort und schickt das Ergebnis zurück an den Server
3. Der Server berechnet ebenfalls den Hash vom Salt + richtiges Passwort und kann die Ergebnisse vergleichen
Der Sniffer weiß zwar den verwendeten Salt und Hash, kann diesen jedoch nicht mehr benutzen, weil der Server beim nächsten Mal einen anderen Salt und somit Hash verlangt. Natürlich kann man jetzt immernoch das Passwort per BruteForce versuchen zu knacken, Rainbow-Tables sollten jedoch nutzlos sein.
matze - Do 19.07.07 09:53
ja ich denke die Methode von Chryzler ist wohl die Beste und so werde ich das dann auch implementieren.
BenBE - Sa 21.07.07 21:30
So wird das IMHO sogar bei meebo.com gemacht.
Da wird das ganze auf Grund von AJAX aber so weit getrieben, dass der Salt nicht bereits in der Ursprungsseite steht, sondern erst beim eigentlichen Login vom Server geholt wird, bevor die Form Submittet wird.
Wenn kein JS aktiviert ist hat dies sogar den Vorteil, dass der Server dies automatisch mitbekommt, da im Form kein Salt gesetzt ist; hat aber den Nachteil, dass das Passwort in diesem Fall unverschlüsselt übertragen wird.
Chryzler - So 22.07.07 14:05
Wobei, wenn der Angreifer die Möglichkeit hat, Daten zu verändern, durch einen Proxy zum Beispiel, dann könnte er den Salt auf "" setzen, der Client hasht dann brav das Passwort ohne Salt und der Angreifer kann dann Rainbow-Tables oder ähnliches einsetzen um das Passwort zu knacken. Abhilfe: Der Client müsste nur überprüfen, ob der Salt vom Server auch wirklich 8 Bytes oder länger lang ist. ;)
BenBE - So 22.07.07 16:02
Brauch er doch nicht mal. Salt-Wert nicht Plain aufnehmen, sondern MD5. Damit ist der Wert immer Saltet, egal was der Server sendet. Außerdem kann man solch einem Angriff vorbeugen, wenn man zusätzlich einen Client-Salt verwendet. Selbst wenn ein Angreifer den Code nun manipuliert, müsste ein Angreifer speziell für diesen Fall eine Rainbow-Table aufbauen.
Also:
Quelltext
1:
| document.all.pwfield.value = md5('Secure:' + md5(document.all.clientsalt.value) + ':' + md5(document.all.srvsalt.value) + ':' + md5(document.all.pwfield.value)); |
Wenn der ClientSalt nun auf Werten basiert, die nur der Server und Client beeinflussen können (also angenommen der verwendete Browser währe solch ein Attribut), dann könnte eben diese Angabe entfallen und somit bräuchte kein ClientSalt übertragen werden.
Welche Werte sich für den Client-Salt in der Praxis eignen, müsste man schauen. Eine Idee wäre, dass man die Dokument-Header (incl. ETags) nimmt und eine Reproduktion dieser mit einem Stream-Chiffre verpackt. Eine Änderung des Dokumenten-Inhaltes würde dann dazu führen, dass keine gültige Authentifizierung mehr möglich wäre, da der ETag eines Dokuments auf seiner Prüfsumme (u.a.) basiert (IIRC). Da man Server-Seitig eh den Passwort-Hash gespeichert hat, kann dieser zum Dekodieren des Client-Salts verwendet werden.
* ETagg: HTTP-Header-Field, was normalerweise dafür genutzt wird, um das Caching zu unterstützen.
matze - Di 24.07.07 20:49
Vielen vielen Dank an alle die sich hier für mich Zeit genommen haben.
Ich werde das bei Zeiten dann mal implmentieren :-)
BenBE - Di 24.07.07 23:51
Ich glaube, die meisten würden sich auch über eine kleine Beispiel-Implementation freuen ;-) Viel Erfolg! ;-)
BenBE - Mi 25.07.07 19:18
Einmal Wiki lesen hätte gezeigt, dass das reine DH-Kex gegen MitM anfällig ist.
Um das zu umgehen, einfach mit dem ausgehandelten Schlüssel salzen ;-)
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!