Autor Beitrag
matze
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 4613
Erhaltene Danke: 24

XP home, prof
Delphi 2009 Prof,
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 4106
Erhaltene Danke: 13


Delphi 2010 Pro; Delphi.Prism 2011 pro
BeitragVerfasst: Mi 18.07.07 15:05 
-SSl
-ein Senden des Passwortes kann durch Hashen und Übertragen dessen umgangen werden.

_________________
Markus Kinzler.
matze Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 4613
Erhaltene Danke: 24

XP home, prof
Delphi 2009 Prof,
BeitragVerfasst: 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.
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2750

Windows Vista
Delphi 7, Delphi 2005 PE, PHP 4 + 5 (Notepad++), Java (Eclipse), XML, XML Schema, ABAP, ABAP OO
BeitragVerfasst: Mi 18.07.07 15:57 
Nach JS und MD5 gegoogelt:
pajhome.org.uk/crypt/md5/md5src.html

_________________
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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 4106
Erhaltene Danke: 13


Delphi 2010 Pro; Delphi.Prism 2011 pro
BeitragVerfasst: Mi 18.07.07 15:59 

_________________
Markus Kinzler.
Christian V.
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 311

Win Xp Prof
Turbo Delphi 2005
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starofftopic starofftopic starofftopic starofftopic star
Beiträge: 324
Erhaltene Danke: 2

Linux

BeitragVerfasst: Mi 18.07.07 17:37 
user profile iconmkinzler 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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 1097
Erhaltene Danke: 2



BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 4613
Erhaltene Danke: 24

XP home, prof
Delphi 2009 Prof,
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 8721
Erhaltene Danke: 191

Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 1097
Erhaltene Danke: 2



BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 8721
Erhaltene Danke: 191

Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
BeitragVerfasst: 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:
ausblenden 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 4613
Erhaltene Danke: 24

XP home, prof
Delphi 2009 Prof,
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 8721
Erhaltene Danke: 191

Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 25

SuSE Linux, Windows XP
BDS06
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 8721
Erhaltene Danke: 191

Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
BeitragVerfasst: 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.