Autor |
Beitrag |
matze
Beiträge: 4613
Erhaltene Danke: 24
XP home, prof
Delphi 2009 Prof,
|
Verfasst: Mi 18.07.07 15:00
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
_________________ In the beginning was the word.
And the word was content-type: text/plain.
|
|
mkinzler
Beiträge: 4106
Erhaltene Danke: 13
Delphi 2010 Pro; Delphi.Prism 2011 pro
|
Verfasst: Mi 18.07.07 15:05
-SSl
-ein Senden des Passwortes kann durch Hashen und Übertragen dessen umgangen werden.
_________________ Markus Kinzler.
|
|
matze
Beiträge: 4613
Erhaltene Danke: 24
XP home, prof
Delphi 2009 Prof,
|
Verfasst: Mi 18.07.07 15: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?
_________________ In the beginning was the word.
And the word was content-type: text/plain.
|
|
Marco D.
Beiträge: 2750
Windows Vista
Delphi 7, Delphi 2005 PE, PHP 4 + 5 (Notepad++), Java (Eclipse), XML, XML Schema, ABAP, ABAP OO
|
Verfasst: Mi 18.07.07 15:57
_________________ Pascal keeps your hand tied. C gives you enough rope to hang yourself. C++ gives you enough rope to shoot yourself in the foot
|
|
mkinzler
Beiträge: 4106
Erhaltene Danke: 13
Delphi 2010 Pro; Delphi.Prism 2011 pro
|
Verfasst: Mi 18.07.07 15:59
_________________ Markus Kinzler.
|
|
Christian V.
Beiträge: 311
Win Xp Prof
Turbo Delphi 2005
|
Verfasst: Mi 18.07.07 17:15
Und was wenn der Browser kein JS untersützt, bzw deaktiviert hat?
_________________ Hardware runs the world, software controls the hardware, code generates software - Have You already coded today?
|
|
r2c2
Beiträge: 324
Erhaltene Danke: 2
Linux
|
Verfasst: Mi 18.07.07 17: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
_________________ Kaum macht man's richtig, schon klappts!
|
|
Chryzler
Beiträge: 1097
Erhaltene Danke: 2
|
Verfasst: Mi 18.07.07 17: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
Beiträge: 4613
Erhaltene Danke: 24
XP home, prof
Delphi 2009 Prof,
|
Verfasst: Do 19.07.07 08:53
ja ich denke die Methode von Chryzler ist wohl die Beste und so werde ich das dann auch implementieren.
_________________ In the beginning was the word.
And the word was content-type: text/plain.
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Sa 21.07.07 20: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.
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Chryzler
Beiträge: 1097
Erhaltene Danke: 2
|
Verfasst: So 22.07.07 13: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
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: So 22.07.07 15: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.
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
matze
Beiträge: 4613
Erhaltene Danke: 24
XP home, prof
Delphi 2009 Prof,
|
Verfasst: Di 24.07.07 19:49
Vielen vielen Dank an alle die sich hier für mich Zeit genommen haben.
Ich werde das bei Zeiten dann mal implmentieren
_________________ In the beginning was the word.
And the word was content-type: text/plain.
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Di 24.07.07 22:51
Ich glaube, die meisten würden sich auch über eine kleine Beispiel-Implementation freuen Viel Erfolg!
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
RedBaron2k7
Beiträge: 25
SuSE Linux, Windows XP
BDS06
|
Verfasst: Mi 25.07.07 00:32
Stichwort sollte evtl. "Diffie-Hellman" sein aber ohne JavaScript kommste ne weit ^^
de.wikipedia.org/wik...l%C3%BCsselaustausch
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Mi 25.07.07 18: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
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
|