Session ID in Datenbank speichern?

[[BUZ]]

Hallo,
ich möchte mir ein kleines Loginscript selber schreiben.
Nach meiner (begrenzten) Vorstellung könnte das so laufen:

User Name, PW und User-ID stehen in der DB. Beim Login werden Username und PW geprüft und der Benutzer im "Gutfall" angemeldet. D.h. die Session wird gestartet. In der Session stehen die User ID und die aktuelle IP des Users (bei Änderung der IP wird User abgemeldet).

Soweit findet man auch x Tutorials wie das geht. Manche Loginscripte speichern die Session-ID auch in der Datenbank.

Nun zu meiner Frage, warum braucht man die Session-ID in der Datenbank? Was macht man damit? Kann der User die in der Session gespeicherten Informationen selbst ändern (Cookie ist ja auf seinem Rechner)?

Gruß

[S2B]

Die Session-ID ist deine "Login-Information nach dem Login". Beim Login gibst du Benutzername und Passwort ein, um dich einzuloggen, nachher "gibst" du dem Server deine Session-ID aus dem Cookie bzw. GET-Parameter.

[larsneo]

bei Änderung der IP wird User abgemeldet

obacht, damit verabschiedest du dich von z.b. aol-usern - dort kann erstaunlicherweise innerhalb einer sitzung die ip wechseln

nachher "gibst" du dem Server deine Session-ID aus dem Cookie bzw. GET-Parameter.

ich würde empfehlen die session id generell nur über cookies auszuliefern. selbst wenn httponly noch in den kinderschuhen steckt ist es auf jeden fall die sichere variante vor session-hijacking.

[[BUZ]]

Hallo,

danke für die Antworten. Aber ich verstehe es immer noch nicht richtig.

@ SB2:
Da ich in meiner Session eine User-ID speichere, kann ich diese zur späteren Identifikation verwenden. Warum also die Session-ID verwenden. Zumal es leichter möglich ist, sich eine Session-ID abzuschauen wie die in der Session gespeicherte Information.

@larsneo:
Ja, dessen bin ich mir im klaren. Aber, sofern sich jemand eine Session-ID abschaut, könnte er über diese ins System. Wenn ich die IP immer mit vergleiche, müsste er neben der Session-ID auch die richtige IP zur Session-ID haben. Dies ist zwar in Netzwerken bei denen sich mehrere Rechner über einen Rechner (oder Sonstiges) anmelden auch möglich, jedoch eher unwahrscheinlich. Da meist hier auch die entsprechende Räumliche Trennung fehlt, könnte man der "Bösewicht" einfacher ausfindig machen. AOL Benutzer haben halt die "Arschkarte" gezogen.

Gut, wie könnte jetzt ein "sicheres" System vom Prinzip her laufen?
Warum wird das System "sicherer" sofern ich die Session-ID in der DB speichere und ??? >>>Bitte erklären ???<<< damit mache.

Gruß

[larsneo]

Aber, sofern sich jemand eine Session-ID abschaut, könnte er über diese ins System

als option mag es ja gut sein, generell würde ich aber eher auf z.b. den USER_AGENT setzen.

Gut, wie könnte jetzt ein "sicheres" System vom Prinzip her laufen?

das lässt sich sicherlich nicht in ein paar sätzen erklären. die grundidee im keks nur die sid zu speichern und über einen eigenen session-handler den rest selber zu verwalten ist sicherlich nicht verkehrt. das bereits angesprochene httponly ist (vielleicht neben p3p) tatsächlich eine gute idee von microsoft in bezug auf sicherheit, leider aber noch nicht durchgängig verbreitet.
als anregung vielleicht mal einen link auf de zukünftigen session-handler von postnuke