Hallo!
Ist es möglich, dass man eine recht sichere Session über den Request erstellen kann, ohne unbedingt Session-Daten zu speichern, z.B. via Cookies oder in einer Datenbank?

Ich hatte mir das so gedacht:
Meine bisherige Session:


Dazu wollte ich jetzt noch, außer der eindeutigen Zufallszahl eventuell noch eine jeweils für jeden Spieler festgelegte, einzigartige ZufallsID anlegen. Wieso weis ich jetzt nicht mehr genau, ich kam in Französisch drauf. :)

Jedenfalls besteht das Problem eindeutig darin, eine Session im Request zu übergeben, die den User, den letzten Seitenaufruf und eine eindeutige ID enthält, und mit der ich den User auch identifizieren kann.
Ich glaube, es geht mit der Zufallszahl, es leuchtet mir nur noch nicht ein.

Ein einfaches Beispiel: Klassiches Spiel, der User A geht in seinen Account und baut etwas in seiner Stadt.
Jetzt geht User B hin, nimmt sich seinen Request und trägt einfach die Koordinaten der Stadt des Spielers A ein und bricht den aktuellen Bau ab.
Das muss ich ja verhindern.

Am besten so, dass nicht jeder Depp hingehen kann und in die Session sid=1066151397XYpktmXY0PT169158935546875 seinen Namen reinschreibt und dann in dem Account eines anderen rumfuchteln kann.

Problem klar?
Ich versuche mich derweil mal noch in ein paar Ansätzen.
Bitte nicht hier posten, wie man es mit Speichern von Daten am besten löst, wenn ihr dieses Bedürfnis verspürt freue ich mich über PM.
mfg pktm

Was wäre wenn du ne verschlüsselte Session ID übergibst, denn die könnte man nicht so leicht verändern? Dafür könntest du DES oder IDEA als Verschlüsselungsverfahren benutzen.

[quote=pktm,16.10.2003, 17:09]Ist es möglich, dass man eine recht sichere Session über den Request erstellen kann, ohne unbedingt Session-Daten zu speichern, z.B. via Cookies oder in einer Datenbank?[/quote]
Du willst nicht, dass jemand einfach die Session ID klaut? Wie wäre es, die IP-Adresse des Besuchers in der ID zu verschlüsseln?

Zuerst dachte ich, nur mit Daten in Cookies könnte man das absichern. Aber den Cookie kann man ja genauso sniffen wie die Session ID. Die IP-Adresse jedoch macht's schon schwerer.

aber zum thema ip, ich hab internet mit NAT vom provider,
soll heißen, wenn jemand der beim selben provider ist die sid klaut,
kann er trotzdem in den account rein und rumpfuschen!!

Quote

Du willst nicht, dass jemand einfach die Session ID klaut? Wie wäre es, die IP-Adresse des Besuchers in der ID zu verschlüsseln?

Zuerst dachte ich, nur mit Daten in Cookies könnte man das absichern. Aber den Cookie kann man ja genauso sniffen wie die Session ID. Die IP-Adresse jedoch macht's schon schwerer.

Sicherer wäre es, wenn in der verschlüsselten ID auch ein Zeitstempel enthalten ist, damit diese nicht unbegrenzt gültig ist. Die IP Adresse würde ich nicht speichern, da nicht jeder direkt auf die Seite zugreift. (Proxy)

Die IP-Adresse ist auch nicht wirklich sicher, wenn man bedenkt, dass einige Leute auch zB ueber den T-Offline-Proxy reingehen

[quote=betterworld,18.10.2003, 16:36]Die IP-Adresse ist auch nicht wirklich sicher, wenn man bedenkt, dass einige Leute auch zB ueber den T-Offline-Proxy reingehen[/quote]
Das war mir bewusst, aber es gibt kaum bessere Möglichkeiten, einen Benutzer zu identifizieren, wenn er sich nicht authentifizieren (anmelden o.ä.) soll.

Wo der Thread gerade auftaucht...
Ich habe an Daten:
* USN (username)
* UNIQ (unique-id aus DB)
* timestamp
* UID (user-id)
* rand(1)
Jetzt meine Idde, wobei XY Trennzeichen für die Abschnitte sind:
UID*UNIQ XY timestamp XY UNIQ XY rand(1) XY UID
ersteres muss ich nochirgendwie drehen, tauschen oder sonst wie verändern, damit nicht gleich jeder Depp sieht, wie sich die Zahl zusammen setzt.
Beim Login wird der timestamp gesetzt, er dient als Anhaltspunkt, wann die Session abgelaufen ist (z.B. 6000ms).
Dann wird in der DB das Feld "UNIQ" gsetzt, da ich sowieso zu dieser connecten muss um USN & PWD abzufragen.
Die UNIQ wird bei jedem relevanten SQL-Query neu gesetzt ( => rand(1) )
Dann übergebe ich ja UID und UNIQ und den zusammengewürfelten Wert, so dass ich dann beim nächsten Script zurück rechnen kann, ob das auch der User ist.
Und das auch ihne DB-connect.
Öhm, dann war da noch die Zufallszahl...
Hab vergessen wofür ich die wolte.
Sagen wir, sie soll den Typen, der versucht hinter das Konzept zu steiegen um einen Acc zu knacken verwirren ^^

Zukünftiges:
Sollte es sich rentieren kann man auch noch einen 2. timestamp einbauen der z.B. angibt, wann die nächste aktualisierung der Daten aus der Datenbank stattfinden soll.
Also wenn sich jetzt in den nächsten 20 min nichts ändern würde (steht ja in der DB drin) kann man das angeben und spart sich so die nächsten 20min jeden SQL-Query, sofern nicht irgendwas an Aktionen (von User aus) unternommen wird.

Was sagt ihr dazu?
mfg pktm