Thema sicheres cookie

cottton

Moin,
... oder abend ...

Da ich mein "CMS" gerade neu schreibe und bei den Cookies gelandet bin, dachte ich ich frag mal in die Runde, ob jemand noch Ideen hat.

Wies bei mir momentan aussieht:
- user eingeloggt
- cookie Nr1 setzen (user id und pw hash)
- cookie Nr2 setzen (user id und validation hash)
- validation hash von cookie Nr2 in db speichern

Der validation hash von Cookie Nr2 besteht momentan "nur" aus dem simplen Fingerprint des Browsers via HTTP_USER_AGENT, HTTP_ACCEPT ect.
Das ist aber nicht genug, find ich.

Hat jemand (PHP seitig) noch Ideen, wie man den Benutzer (ausser IP) noch eindeutiger identifizieren kann?
(Thema https://panopticlick.eff.org allerdings Serverseitig gewünscht)

The Scout

Beim zweiten Cookie neben dem Fingerprint des Browsers noch eine temporaere ID speichern (sowohl im Cookie, als auch in der DB) und jedes Mal, wenn der User wieder auf die Seite kommt, diese ID aendern...
Dann hast du ein Cookie mit dem PW Hash und eins mit der EinmalID. Selbst wenn sich jetzt jemand als Man-in-the-Middle zwischenschaltet, und die Daten kriegt, bringt es ihm nicht mehr viel, da er nur Infos fuer einmal bekommen koennte.

Dann noch eine Mail, wenn das PW geaendert wird, senden und schon weiss der der Besitzer des Accs, dass da was beim letzten Mal faul war.

cottton

Du meinst wenn cookie verified und korrekt, dann diese ID erneuern
damit ein geklautes cookie mit der "alten" ID abgelehnt wird?

The Scout

Jiop.

cottton

Hier gibts noch ein Problem.
Ich wollte das, oder besser hatte das schon eingebaut. Dann viel mir auf:
- es muss bei jedem Seitenaufruf das cookie neu geschrieben/erstellt/gesendet werden
- bei senden/erstellen des cookies kann es abgefangen werden (weswegen wir die id ja einbauen wollten)

Und, naja ... wer als erstes kommt, malt zuerst.
Heißt : Angreifer ist nicht wirklich gehindert worden.

Wäre also eher eine Art "Verschleierung" =/

The Scout

"malt zuerst"? Ich dachte immer, es ginge bei dem Spruch um Mehl, nicht um Kunst?

Wegen dem Cookie neu erstellen: das ist ja nur ein bisschen Text, das geht jetzt nicht wirklich auf die Performance mMn
Ansonsten hast du dieses Problem mit Cookies und Man-in-the-middle immer, solange man sich kein https Zertifikat kauft
Das einzige, was mir sonst noch einfallen wuerde, waere, das Ganze erstmal via JavaScript localStorage zu machen, mit Fallback Alternative auf Cookies fuer JS Phobiker.
Dann wuerde das Ganze seltener gesendet werden und der Man-in-the-middle haette weniger Chancen.

Oder du fragst einfach mal ganz dreist bei Google oAe an, wie die dieses Problem geloest haben

cottton

dann eben "wer zuerst kommt, lacht am besten"
An localStorage hab ich auch schon gedacht.
Könnte man einbauen.

The Scout

Ich hab da mal ein nettes JavaScript gefunden, welches genau das bringt: localStorage wenn moegl, sonst Cookie.
Kannst du ja mal nach suchen im Inet, sonst geduldest du dich, bis ich daheim bin.

Aber ich hab zu dem Thema noch was bei der W3C gesehen: http://www.w3.org/TR/2013/REC-webstorage-20130730/#privacy
Ab da anfangen zu lesen, nach dem Absatz kommt Security. Und dann nochmal drueber nachdenken ...
Also, Shared Hosting und localStorage zusammen -> keine gute Idee!

Ich bin aber vor Kurzem ueber http://www.netcup.de/ gestolpert, von der Qualitaet kA, aber die bieten relativ guenstige vServer (laut eigener Aussage immer die guenstigsten) an, da waere das Problem beseitigt. Dafuer haette man mehr Arbeit ...

Jetzt mitmachen!