spricht was dagegen eingene sessions-id erzeugen ??

[Philipp Hasenfratz]

Halihallo

Die SessionID nimmt z. B. linear zu (auto-increment Wert aus der DB), dazu wird ein SessionKey generiert (z. B. kombination aus Zeit, SessionID und meinetwegen einer kodierten "or" Operation mit HTTP_USER_AGENT und REMOTE_ADDR). Die SessionID, SessionKey und Sessiondaten werden dann in einer Tabelle gespeichert.

warum so kompliziert? Ein Timestamp in Kombination mit einer (fast echten) Zufallszahl und das ganz MD5-gecryptet reicht doch auch, oder?

Ja, selbstverständlich ;-)
Den User-Agent und die IP mitzukodieren ist schon etwas Luxus ;-)

Man könnte in der Sessiontabelle auch die Session-ID an die IP und Useragent binden. Das reduziert die Chance von Angriffen auch, da es einige Faktoren mehr zu "erraten" gibt.

Deswegen habe ich ja auch noch den User_Agent und die Remote_addr (IP) oben aufgeführt

Bindung an eine IP hat aber den Nachteil, dass es bei Clients mit dynamisch zugewiesenen IPs (z.B. Dialup-Accounts) schnell mal zu Problemen kommen kann.

Deswegen die Aufteilung in SessionID und SessionKey...
Der SessionKey wird ja nur einmal generiert und mit der entsprechenden SessionID in der Datenbank verknüpft. Und da der Key nur einmal generiert wird, kann man auch gut die IP des Clients mitkodieren; aber dann muss der SessionKey jedesmal mit der SessionID mitgeschleppt werden, da er nicht mehr mit 100% Wahrscheinlichkeit rekonstruiert weden kann.

Viele Grüsse

Philipp