Sicherheit bei Login Cookies

Sicherheit bei Login Cookies (14 Beiträge, 362 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich baue im Moment zum Spaß an ein paar experimentellen Webanwendungen und bin jetzt gerade dabei eine User- und Rechteverwaltung inklusive Login und Registrierung via Browser zu realisieren.

Ich habe jetzt über die verschiedenen Möglichkeiten nachgedacht die mir in den Sinn gekommen sind.
Am weitesten verbreitet wird wohl das Cookie sein.

Hier im Forum zum Beispiel wird bei jedem HTTP Request das Login Cookie mit User Id und gehashtem Passwort mitgeschickt.
Ist das nicht unglaublich unsicher?
Es besteht keinerlei Schutz gegen mitm Angriffe. (Angreifer erhält nicht das Passwort, aber vollen Zugriff auf den Account)
Die einzige Möglichkeit Login Cookies halbwegs sicher zu verwenden wäre somit stets SSL/HTTPS zu verwenden, oder?
Warum verwenden dann trotzdem so viele Anbieter von Webservices Cookies via HTTP?

Die folgende Lösung mit einem Cookie das weniger sensible Daten beinhaltet ist mir eingefallen.
Bei jedem Login wird für den Useraccount mit dem der Login stattgefunden hat die IP Adresse eingetragen und ein Cookie mit einem random generierten Key zurückgesandt.
Fortan werden nur noch Zugriffe von dieser IP erlaubt und es muss dieses Cookie mitgeschickt werden.

Sollte sich die IP ändern muss man sich neu einloggen.
Die Sicherheit steigt außerhalb des eigenen Netzwerks:
Sofern man nicht von der IP Adresse des Benutzers senden kann bringt einem das Cookie nichts.

test

Hier im Forum zum Beispiel wird bei jedem HTTP Request das Login Cookie mit
User Id und gehashtem Passwort mitgeschickt.

Kurz mal die SuFu verwendet und du wüsstest, dass das schon des Öfteren ein Thema gewesen ist.

Die folgende Lösung mit einem Cookie das weniger sensible Daten beinhaltet ist
mir eingefallen.
Bei jedem Login wird für den Useraccount mit dem der Login stattgefunden hat
die IP Adresse eingetragen und ein Cookie mit einem random generierten Key
zurückgesandt.
Fortan werden nur noch Zugriffe von dieser IP erlaubt und es muss dieses
Cookie mitgeschickt werden.
Sollte sich die IP ändern muss man sich neu einloggen.
Die Sicherheit steigt außerhalb des eigenen Netzwerks:
Sofern man nicht von der IP Adresse des Benutzers senden kann bringt einem das
Cookie nichts.

Dann müsste man sich jedesmal neu einloggen, wenn man das Gerät bzw. das Netzwerk wechselt.

Außerdem ist es auch möglich, dass ein Client eine variable IP hat (Proxy mit Load-Balancing, etc.). Kommt zwar heutzutage nur mehr selten vor, aber ist trotzdem möglich.

Warum verwenden dann trotzdem so viele Anbieter von Webservices Cookies via
HTTP?

weils wurscht ist - wenn du dich schon unsicher einloggst, ist der cookie inhalt auch schon egal.

Warum nicht die Verwendung von https erzwingen?
Der Aufwand ist doch gering.

test

auf serverseite korrekt. auf browserseite sieht die sache schon mal anders aus.

willst bspw. alles in tls 1.2 realisieren mit guter verschlüsselung, pfs und ähnlichem, wirst damit jede menge an kunden auf allen plattformen vertreiben.

willst bspw. alles in tls 1.2 realisieren mit guter verschlüsselung, pfs und
ähnlichem, wirst damit jede menge an kunden auf allen plattformen vertreiben.

und wenn ENDLICH JEDER Internetdienst die alten Standards abschalten würde, so wird jeder GEZWUNGEN sein drecks veraltetes system upzudaten.

aber nein wir unterstützen ja immer noch IE6 damit ja der größte vollidiot im internet auf diese seite zugreifen kann.

Hier im Forum zum Beispiel wird bei jedem HTTP Request das Login Cookie mit
User Id und gehashtem Passwort mitgeschickt.

Stimmt ja gar nicht ... Es wird nur ein (sehr langer) token übertragen (Zufallsstring).

(Angreifer erhält nicht das Passwort, aber vollen Zugriff auf den Account)

Naja, er kann das Passwort nicht ändern. Und ohne irendwelche session-bezogene Informationen zu übertragen, geht's halt nicht.

Die einzige Möglichkeit Login Cookies halbwegs sicher zu verwenden wäre somit
stets SSL/HTTPS zu verwenden, oder?

Richtig - und HSTS wäre eine halbwegs brauchbare Lösung (haben wir tw. im Einsatz).

Fortan werden nur noch Zugriffe von dieser IP erlaubt und es muss dieses
Cookie mitgeschickt werden.

Man könnte die IP schon mitspeichern (oder wie bei Heise optional beim Login), aber dann kann man z.B. keine rotierenden Proxies, Tor o.ä. verwenden.

Sofern man nicht von der IP Adresse des Benutzers senden kann bringt einem das
Cookie nichts.

Man kann die sendende Adresse faken und wenn man einen MITM-Zugang hat, ist das Empfangen der Ergebnisse sicherlich auch kein Problem.

Google-Suchergebnisse, nur mit Privatsphäre? startpage.com!

Once you allow the government to start breaking the law, no matter how seemingly justifiable the reason, you relinquish the contract between you and the government which establishes that the government works for and obeys you, the citizen—the employer—the master. And once the government starts operating outside the law, answerable to no one but itself, there’s no way to rein it back in, short of revolution. -- John W. Whitehead

Zwangsbejagung Ade!

Richtig - und HSTS wäre eine halbwegs brauchbare Lösung (haben wir tw. im
Einsatz).

sorry. HSTS ist für mich ein marketing gag. was macht das sicherer als wie wenn ich bspw. mit nginx auf meiner seite alles permanent auf https umleite. damit hat der client auch exakt 0 möglichkeit den content per http abzurufen. wenn ich noch altmodischer bin dreh ich den http port komplett ab.

wir haben bei uns zwar überall HSTS im einsatz, weil das 0 mehr aufwand in der config ist, als riesensicherheit seh ich das aber nicht. http ist entweder komplett deaktiviert oder jeder request wird vom server selbst auf https umgeschrieben.

was macht das sicherer als wie wenn ich bspw. mit nginx auf meiner seite alles
permanent auf https umleite.

Ein MITM kann dem client den traffic ohne https ausliefern und dieser erkennt es nicht ...

Aber gut, der kann auch den HSTS-Header löschen. Dagegen hilft die lange Gültigkeitsdauer des Headers (im Client).

das stimmt wohl.

nur sind mal wieder millionen windows / IE nutzer aussen vor. HSTS kann der redmond browser erst mit version 12. aber gut wer IE einsetzt, der legt auf sicherheit eh weniger wert.

also ich hab IE11 (nicht in Verwendung, kommt halt mit W7 mit) und HSTS funktioniert

Man kann die sendende Adresse faken

Wie?

test

die idee mit dem neu einloggen ist gut, und wird auch öfter mal eingesetzt. solltest du firmenkunden haben, solltest du die möglichkeit einrichten das der user diesen check ausschalten kann bzw. durch eine whitelist von ip adressen ersetzen kann. im firmenumfeld hast du bald mehrere proxies mit unterschiedlichen ips und dann ist die anwendung nicht brauchbar.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung