Diese Variablen werden _nach_ erfolgreichem Login definiert und dienen bei weiteren Requests zur Überprüfung eines bereits eingeloggten Benutzers. Der eigentliche Login ist also meiner Meinung nach die Authentifizierung.

Aber stimmt schon, ich hätte deutlicher hervorheben sollen, dass die Session Variable einen eingeloggten Benutzer identifiziert. Werd ich gleich machen.

Und die alte Session muss man in diesem Beispiel nicht löschen, da sie keine bzw. nur unwichtige Daten enthält und sowieso später vom Server gelöscht wird. Das kommt halt immer drauf an, welche Daten in Sessions gespeichert werden.

Ansonsten eine wirklich interessante Diskussion. Sowas müsste es öfter geben. Danke für die Kommentare und jetzt sind wir uns hoffentlich einig

Meine Aussage ist so nicht gerechtfertigt : “Befolgt man obiges Tutorial, so ensteht genau dieses Problem.” : Auch wenn es nicht besonders herausgestellt wurde im eigentlichen Tutorial, so hast du natürlich recht, $_SESSION['eingeloggt'] (‘user’) wird erst nach dem Erneuern der SID gesetzt. Dies ist allerdings genau der Punkt auf den ich bei meinem allerersten Post hinaus wollte! Das Setzen von $_SESSION['eingeloggt'] (‘user’) = true ist ja das eigentliche Einloggen und erfolgt nach der Erneuerung der SID. Die Überprüfung von Benutzername und Passwort davor, sind als Authentifizierung und somit nur als Teil des gesamten Loginvorganges zu sehen.

Somit stimmen wir jetzt überein ?
“Man sollte generell eher vor dem Login die ID erneuern, nicht DANACH.”

Allerdings steht folgender interessanter Punkt noch aus:
* @param delete_old_session bool[optional]
* Whether to delete the old associated session file or not. Defaults to
* false.

Natürlich müsste man hier dann die entsprechende Variable überprüfen. Sonst wär sie ja überflüssig.

Hier mal ein vereinfachtes Beispiel: http://nopaste.us/621.html

1. Angreifer legt SID fest: SID=1234
2. User Login (SID=1234&pass=abc), neue SID, $_SESSION['eingeloggt'] = true
3. SID=1234 ist nicht eingeloggt, da die Session Variable nicht existiert. Diese ist nur der neuen SID zugeordnet, die der Angreifer nicht kennt.

1. SID=1234
2. user login
3. SID=1234 ist eingeloggt
4. regnerate_id -> SID=5678
5. keine invalidierung der alten SID -> in der Session mit ID=1234 sind immernoch alle credentials gespeichert, auch wenn der user jetzt ID=5678 benutzt.

Befolgt man obiges Tutorial, so ensteht genau dieses Problem.
Laut Quellcode soll die SID durch folgenden Ausdruck erneuert werden:

session_regenerate_id();

Allerdings wird nicht erwähnt, dass man für die Invalidierung der alten SID “true” übergeben müsste. Hier der Auszug aus der Session.php :

* @param delete_old_session bool[optional]
* Whether to delete the old associated session file or not. Defaults to
* false.

Beachte : default = FALSE.

Will man sich also wirklich gegen Session Fixation schützen, so sollte man VOR dem login regenerate_id() aufrufen und/oder regenerate_id(true) nutzen.

Auch nachzulesen in der (englischen) Wikipedia:

“Best solution: Identity Confirmation
This attack can be largely avoided by changing the session ID when users log in.”

In diesem Artikel geht es um das Thema Session Sicherheit in PHP. Teil 1: Session Fixation….