nicht angemeldet
Moin!
Dein Szenario mal in Stichpunkten:
...
- Client generiert $logpwd = MD5($pwd) + $zuffi
Nein, logpwd = md5( md5( pwd ) + zuffi )
Nahezu irrelevant. Ergebnis ist ein String, mit dem man beim Server eine authentifizierte Aktion ausgeführt bekommt. Replay-Angriffe sind möglich.
- Client sendet $logpwd
...Der Mann in der Mitte kennt also sowohl die Generierungsvorschrift für $logpwd als auch den Zufallswert $zuffi.
Kann aber mit bekanntem "logpwd", "zuffi" und "logpwd = md5( md5( pwd ) + zuffi )" nicht auf "md5( pwd )" und schon gar nicht auf "pwd" schließen, oder ? Und damit eben nicht durch reine Beobachtung der Kommunikation selbst eine Anmeldung durchführen. Im Gegensatz zu den etablierten Methoden.
Wenn $zuffi bekannt ist und sich nicht ändert, reich die Kenntnis von $logpwd.
Der Angreifer kennt die Mechanismen und könnte Code einfügen, der a) das Klartextpasswort oder b) dessen eigentlich nur notwendigen MD5-Hash mitsendet, um dann Manipulationen durchzuführen und gegenüber dem Server zu autorisieren.
OK, in der Mitte mit direkter Möglichkeit zur Manipulation geht auf Basis von Http eins wohl immer : Auf eine passende Anfrage des Clients warten. Mit etwas antworten, das gleich wie das vom Nutzer Erwartete aussieht. Dann aber das Klartext-Kennwort versendet.
Und nachdem der Server bei diesem Vorgang noch nicht einmal involviert ist, kann hier logischerweise rein gar nichts entgegengesetzt werden.
Und das sichert SSL eben ab.
... Das ist genau der Punkt: Wenn ein Angreifer tatsächlich die Kommunikation beobachten kann, wird es ihm in der Regel auch ein Leichtes sein, sie zu verändern. Geh' davon aus, dass das der Fall ist, alles andere würde kaum Sinn ergeben. Mann in der Mitte zu werden ist keine sehr leichte Sache - wer das schafft, kann auch manipulieren, wenn er will.
Wenn man das so sieht. Dann lohnt sich bei Verwendung von Http allerdings keine wie auch immer geartete Absicherung.
Richtig.
Meines Wissens sind allerdings die Beobachtung von übertragenen Daten einerseits und die Manipulation einer Socket-Verbindung plus Generierung ähnlicher Inhalte mit der Entwicklung eines veränderten Verhaltens andererseits bezüglich der Anforderung an den Agierenden zwei paar Stiefel. Und es könnte sich ja lohnen, die Hürde höher zu hängen ...
Es reicht, einen passend gestalteten Proxy-Server per DNS-Poisoning anstelle des Originalservers vorzuschieben. Diese Manipulation würde vom User nicht bemerkt werden können.
Das fälschen eines SSL-Zertifikats für eine Domain hingegen ist um mehrere Größenordnungen unmöglicher.
- Sven Rautenberg