nicht angemeldet
Wert dauerhaft speichern, aber ohne Offenlegung im Http-Header
Dauerhaft im Sinne von "über einzelne Seitenaufrufe hinweg". Gibt es bei JavaScript diese Möglichkeit ? Hintergrund ist der, dass ich damit eine "Mann in der Mitte"-sichere Anmelde-Prozedur auch ohne Https entwickeln könnte.
Cookie-Werte werden meines Wissens immer im Http-Header übers Netz übertragen, fallen also schon mal flach.
Das Erzeugen einer eigenen Eigenschaft im DOM-Objekt "window" könnte vielleicht eine geeignete Methode sein. Bin mir aber nicht sicher, ob das Browser-übergreifend zuverlässig funktioniert. Jemand Erfahrung damit ?
Mit Schließen der Anwendung wäre natürlich Schluss mit "dauerhaft" - wobei sich das Verschmerzen ließe ...
-
Liebe(r) scid,
Gibt es bei JavaScript diese Möglichkeit ? Hintergrund ist der, dass ich damit eine "Mann in der Mitte"-sichere Anmelde-Prozedur auch ohne Https entwickeln könnte.
Cookie-Werte werden meines Wissens immer im Http-Header übers Netz übertragen, fallen also schon mal flach.
Du hast da anscheinend etwas völlig falsch verstanden.
Wenn man eine Anmeldefunktion sinnvoll erstellt hat, dann werden per HTTP die Anmeldedaten exakt _einmal_ vom Client zum Server übertragen. Der kann dann ein Cookie anlegen, aber darin steht dann in der Regel nur ein Hash, der dem Server erlaubt, den User wiederzuerkennen. Zu diesem Hash hat der Server dann gespeichert, ob der User sich erfolgreich angemeldet hat, oder nicht.
Soetwas nennt man eine Session.
Die Session-Daten werden ausschließlich auf dem Server gespeichert und verwaltet. Solange die Session gültig ist (also bevor der User sich wieder abgemeldet hat, oder die Session-Zeit abgelaufen ist), kann sich der User als "eingelogged" auf der Seite bewegen.
JavaScript ist keine Lösung, um Anmeldefunktionalitäten zu regeln. Man kann lediglich mit JavaScript Anmeldefenster einblenden und die dort eingegebenen Daten auf dem herkömmlichen HTTP-Weg zum Server senden, um anschließend den Hash in Empfang zu nehmen. Ansonsten ist JavaScript für Dich uninteressant.
Außerdem: Wenn der Client die Annahme von Cookies verweigert, dann muss eine Alternative her. Das löst man allgemeinhin so, dass der Hash dann eben in der URL als Parameter immer "mitgeschleppt" werden muss. PHP bietet z.B. einen solchem Sessionmechanismus an. Falls Du serverseitig PHP benutzt, wäre das eine Lösung.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Hallo Felix,
Du hast da anscheinend etwas völlig falsch verstanden. ...
Danke für Deine Antwort. Scheint mal wieder die Ähnlichkeit des Gegensätzlichen zum Tragen gekommen. Ist mir alles bekannt, ich versuche im Gegenteil die Schwachstellen der etablierten Methoden auszumerzen.
Wenn man eine Anmeldefunktion sinnvoll erstellt hat, dann werden per HTTP die Anmeldedaten exakt _einmal_ vom Client zum Server übertragen. ...
Genau : unverschlüsselt ( meist im "Post"-Anhang des Http-Requests ) übers Netz. Und dann werden Server-seitig oft "niedliche" Bemühungen gestartet, über Fingerabdruck-Funktionen das in den Brunnen gefallene Kind wieder zu heben. So kommt der Mann in der Mitte aber viel zu einfach an Kennwörter als Reintext ran.
Tut mir leid, das ist mir zu wenig intelligent ! Mit JavaScript kann ich problemlos einen Md5-Schlüssel des Kennworts erzeugen. Damit wird schon mal vermieden, das Kennwort auch nur einmal als Reintext zu übertragen.
Noch besser : Ich kann das Kennwort gemeinsam mit einem Server-seitig gelieferten Zufalls-Schlüssel vermengen und davon den Fingerabdruck übers Netz senden. Was der Mann in der Mitte in die Hände bekäme, wäre dann nur für die aktuelle Sitzung gültig - und würde für eine Wieder-Anmeldung rein gar nichts bringen.
Als drittes könnte ich auch jede Manipulation der Daten und jeden Sitzungs-Diebstahl vermeiden - eben wenn ich nur die Möglichkeit hätte, in JavaScript einen Wert dauerhaft, aber ausschließlich lokal verfügbar zu machen ...
Liebe Grüße - scid
-
Hi,
Tut mir leid, das ist mir zu wenig intelligent !
Und mir das basteln eigener „Lösungen“ für längst gelöste Probleme.
Stichwort HTTPS/SSL.
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
Hi,
Tut mir leid, das ist mir zu wenig intelligent !
Und mir das basteln eigener „Lösungen“ für längst gelöste Probleme.
Stichwort HTTPS/SSL.Mit seinem Kosten und dem Aufwand für die Einrichtung bei jedem einzelnen Webbangebot ? Dann lieber einmal eine etablierte Methode etwas besser durchdenken.
Kann natürlich gut sein, dass ich mich bezüglich des Aufwands und der Möglichkeiten meines Konzepts irre. Das bedarf dann aber einer Diskussion in der Sache.
MfG - scid
-
-
Moin!
Danke für Deine Antwort. Scheint mal wieder die Ähnlichkeit des Gegensätzlichen zum Tragen gekommen. Ist mir alles bekannt, ich versuche im Gegenteil die Schwachstellen der etablierten Methoden auszumerzen.
Meinst du nicht, dass sowas von fähigeren Fachleuten nicht schon längst erledigt worden wäre, wenn es denn ginge?
Wenn man eine Anmeldefunktion sinnvoll erstellt hat, dann werden per HTTP die Anmeldedaten exakt _einmal_ vom Client zum Server übertragen. ...
Genau : unverschlüsselt ( meist im "Post"-Anhang des Http-Requests ) übers Netz. Und dann werden Server-seitig oft "niedliche" Bemühungen gestartet, über Fingerabdruck-Funktionen das in den Brunnen gefallene Kind wieder zu heben. So kommt der Mann in der Mitte aber viel zu einfach an Kennwörter als Reintext ran.
Tut mir leid, das ist mir zu wenig intelligent ! Mit JavaScript kann ich problemlos einen Md5-Schlüssel des Kennworts erzeugen. Damit wird schon mal vermieden, das Kennwort auch nur einmal als Reintext zu übertragen.
Das bringt dir serverseitig aber wenig, denn der Server nimmt dann ja nur das MD5 entgegen - als etwas komplexeres Klartextpasswort. Das abgehört und wieder benutzt werden kann, in einer manipulierten Clientumgebung.
Noch besser : Ich kann das Kennwort gemeinsam mit einem Server-seitig gelieferten Zufalls-Schlüssel vermengen und davon den Fingerabdruck übers Netz senden. Was der Mann in der Mitte in die Hände bekäme, wäre dann nur für die aktuelle Sitzung gültig - und würde für eine Wieder-Anmeldung rein gar nichts bringen.
Der Mann in der Mitte würde sowohl den kompletten Generierungsmechanismus wie auch den serverseitigen Zufallswert kennen und könnte alles beides auch manipulieren. Replay-Attacken sind typische Angriffsvektoren.
Als drittes könnte ich auch jede Manipulation der Daten und jeden Sitzungs-Diebstahl vermeiden - eben wenn ich nur die Möglichkeit hätte, in JavaScript einen Wert dauerhaft, aber ausschließlich lokal verfügbar zu machen ...
Du überschätzt dich maßlos. Wenn man sowas könnte, wäre es bereits erfunden, denn die Preise und Umständlichkeiten von SSL-Zertifikaten sind vielen Leuten ein Dorn im Auge.
Wenn's dir darum geht, Passwörter nicht im Klartext zu übertragen: HTTP-Authentifizierung "Digest" anstatt "Basic" sorgt dafür.
- Sven Rautenberg
-
-
-
Moin!
Dauerhaft im Sinne von "über einzelne Seitenaufrufe hinweg". Gibt es bei JavaScript diese Möglichkeit ? Hintergrund ist der, dass ich damit eine "Mann in der Mitte"-sichere Anmelde-Prozedur auch ohne Https entwickeln könnte.
Das bezweifle ich.
Welches Szenario schwebt dir denn vor, was du "absichern" willst?
Cookie-Werte werden meines Wissens immer im Http-Header übers Netz übertragen, fallen also schon mal flach.
Und ohne Cookieübertragung hat der Server keine Chance zu wissen, ob der Request jetzt von einem authentifizierten User kommt, oder nicht.
- Sven Rautenberg
-
Tag !
Dauerhaft im Sinne von "über einzelne Seitenaufrufe hinweg". Gibt es bei JavaScript diese Möglichkeit ? Hintergrund ist der, dass ich damit eine "Mann in der Mitte"-sichere Anmelde-Prozedur auch ohne Https entwickeln könnte.
Das bezweifle ich.
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.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.
Wenn es eine einfache Möglichkeit gibt, Werte Client-intern zu speichern, scheint mir das Ganze eigentlich einfach umsetzen zu sein.
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.
- Sven Rautenberg
- scid
-
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
-
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.
...
Dein Szenario mal in Stichpunkten:
...- Client generiert $logpwd = MD5($pwd) + $zuffi
Nein, logpwd = md5( md5( pwd ) + zuffi )
- 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.
...
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.... 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.
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 ...- Sven Rautenberg
- scid
-
Hi there,
[...] Dann lohnt sich bei Verwendung von Http allerdings keine wie auch immer geartete Absicherung.
Bingo! Du hast es!
-
Hi there,
[...] Dann lohnt sich bei Verwendung von Http allerdings keine wie auch immer geartete Absicherung.
Bingo! Du hast es!
Hmmm. Das Kennwort könnte man sich also auch gleich sparen, oder ?
- scid
-
Hi there,
Hmmm. Das Kennwort könnte man sich also auch gleich sparen, oder ?
Hängt davon ab, was man vorhat. Es ging Dir um eine "Man in the middle"-Attacke, das ist im Web ja nicht der Normalfall der Bedrohung. Das Kennwort zur Identifizierung dem Sever gegenüber kann sehr wohl notwendig sein, das ändert aber nichts daran, daß das Übermitteln desselben über HTTP einfach nie und nicht einmal annähernd hundertprozentig sicher sein kann, egal, welche Handshake- und sonstigen Prozeduren man sich auszudenken versucht ist.
Wenn etwas wirklich hocheffizient abgesichert sein soll, dann ist HTTP einfach nicht das Protokoll Deiner Wahl...
-
-
-
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
-