Moin!

Ich hab mir den Artikel gerade das erste mal durchgelesen und bin einigermaßen erschüttert. Vorallem weil der Quelltext selbst Sicherheitslücken aufweist:

session_regenerate_id(); // erneuert die Session-ID,

#                         // erschwert Session-Hijacking

>   
> Inwiefern sollte es gegen Session-Hijacking nützlich sein, bei jedem Request eine weitere gültige Session zu erzeugen? Das ist geradezu eine Einladung für Angriffe dieser Art.  
  
Das Erzeugen einer neuen Session-ID ist ein probates Mittel gegen Session-Fixation - d.h. wenn der Angreifer einem einen Link schickt, der eine vom Angreifer vorbereitete Session fortführt, dann ist es für diesen trotzdem unmöglich, auf der Session mitzusurfen, wenn durch den Login die Session unter einer neuen ID fortgeführt wird.  
  
Die alte Session zu verwerfen ist sicherlich schöner, aber man erhält in ihr ja keine weitergehenden Rechte. Der Login ist in der neuen Session.  
  

> ~~~php

if (! function_exists('crypt') ) {  // es gibt auch noch ältere ...  

>    die ("Sorry: Aber Sie sollten Ihr PHP wirklich updaten!");  
> }

Wieso wird hier kein PHP-Fehler produziert, sondern eine Ausgabe an den Endnutzer vorgenommen? Wieso befinden sich diese Zeilen überhaupt irgendwo mitten im Loginskript und nicht ganz am Anfang oder ausgelagert in einem Unterprogramm, das nur die Systemabhängigkeiten prüft?

Mein Einwand war ja, dass überhaupt keine Alternative zur Passwort-API von PHP (password_hash() etc.) selbstprogrammiert werden sollte. Es gibt die Reimplementierung für PHP 5.3 und 5.4, das sollte reichen.

- Sven Rautenberg