Sven Rautenberg: Wert dauerhaft speichern, aber ohne Offenlegung im Http-Header

Beitrag lesen

Moin!

Welches Szenario schwebt dir denn vor, was du "absichern" willst?

Md5-Abdrücke der Kennwörter beim Server hinterlegt. Server sendet zufälligen Schlüssel und speichert diesen.
Bei Anmeldung erstellt Client Md5 des Kennworts, speichert diesen intern. Md5 des Kennworts und zufälliger Schlüssel werden aneinandergefügt, davon Md5 erstellt und dieser versendet.
Server führt gleiche Prozedur durch und vergleicht Ergebnis.

Nur weil ein String vom Aussehen her an "MD5" erinnert, bedeutet das noch lange nicht, dass er automatisch "sicher" ist.

Deine Idee ist mir nicht neu. Sie wurde von diversen Leuten schon vor Jahren als geniale Idee präsentiert, bevor ich ihnen erklärt habe, warum sie sich Unsinn ausgedacht haben.

Dein Szenario mal in Stichpunkten:

$pwd:    Usereingabe eines Passwortes.
$zuffi:  Zufallswert
$logpwd: Generierter Loginpasswortwert

  • Server kennt MD5-Wert vom Passwort: $md5pwd = MD5($pwd)
  • Server generiert Zufallswert $zuffi
  • Client empfängt Zufallswert $zuffi
  • Client generiert $logpwd = MD5($pwd) + $zuffi
  • Client sendet $logpwd
  • Server checkt: Ist $logpwd == $md5pwd + $zuffi ?

Der Mann in der Mitte kennt also sowohl die Generierungsvorschrift für $logpwd als auch den Zufallswert $zuffi.

Er kann also eigene Requests an den Server schicken, die bei demselben Zufallswert $zuffi einfach nur die Antwort $logpwd zurückschicken.

Die erste logische Idee ist, $zuffi bei jedem Request neu zu definieren. Dummerweise läuft HTTP aber so ab, dass erst der Client seine Daten schickt, dann der Server antwortet. Der Client kriegt also $zuffi gleichzeitig mit den geheimen Daten, auf die er Zugriff haben will. Unpraktisch!

Für die ganze Aktion ZWEI HTTP-Requests zu veranstalten ist ebenfalls keine sehr gute Idee, denn ein böser Angreifer könnte den $zuffi-Wert durch eigene Requests schön durcheinander bringen.

Weitere Verarbeitung von Anfragen über gewöhnlichen Php-Sitzungs-Mechanismus.

Will aber Client Datenbank-Inhalte modifizieren, werden Post- oder Get-Anweisungen mit lokalem Kennwort-Md5 aneinandergefügt, vom Ganzen Md5 erstellt und mit versendet. Server überprüft damit, ob "in Mitte" Veränderungen an den Anweisungen vorgenommen wurden.

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.

Wenn es eine einfache Möglichkeit gibt, Werte Client-intern zu speichern, scheint mir das Ganze eigentlich einfach umsetzen zu sein.

Dein Mechanismus würde auch dann scheitern.

Voraussetzung : ich hab' da keinen Denkfehler drin. Und macht Alles natürlich nur Sinn, wenn die Kommunikation von der Mitte zwar nicht modifiziert, aber durchaus beobachtet werden darf. Sonst muss auf das bezüglich Einrichtung und Kosten aufwendigere Https zurückgegriffen werden.

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.

- Sven Rautenberg