Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.

Das hat man doch schon dadruch erreicht, dass die Credentials nur einmal fällig werden und danach auf Session-ID zurückgegriffen wird, um den Nutzer erneut zu identifizieren. Was trägt es da an zusätzlicher Sicherheit bei, die Session-ID ständig zu erneuern?

Man kann mit tcdump bei unverschlüsselten Verbindungen die SESSION-ID mitlesen und die SESSION kapern. Man kann ja das COOKIE mitlesen. Das Problem ist also nicht darauf begrenzt, dass die SESSION über einen Link weiter gegeben wird. Das (ab auf den Zettel damit!) sollte durch ini_set('session.use_only_cookies', 1)  verhindert werden. Könnte ja geändert sein.

Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist.

Also mir sind keine Perfomance-Bottlenecks von HTTPS bekannt und dem Tradeoff Sicherheit für Performance kann ich auch im Allgemeinen nicht viel abgewinnen.

Naja, da hast Du mich falsch verstanden. Ich meinte bei der Verwendung von HTTPS auf die Neuvergabe der SESSION-ID zu verzichten.

Wenn man session_regenerate_id() zudem bei jeder Anfrage ausführt, dann können keine Anfragen des selben Nutzers mehr parallel bearbeitet werden.

Das klingt tatsächlich so als könnte das durchaus ein Problem werden. Ich teste das mal aus und denke über Szenarios nach und darüber, wie man das verhindern kann.

Übrigens. Das "böse" <code>die("Sie sollten")</code>  ... kann theorethisch kein NUTZER der Webseite je zu Gesicht bekommen. Irgendwie müssten die Hashes der Passwörter ja auch erzeugt werden. Und da werde ich unterhalb von crypt() nichts programmieren. Es sei denn natürlich jemand kommt auf die Idee, die Passwörter "manuell" zu hashen  (z.B. auf einem anderen System mit apache 2.4 mit htpasswd -Bbn oder so...) oder aus /etc/shadow zu kopieren...

Wenn wir gerade davon reden: Eine Bindung an PAM wäre übrigens etwas, was ich mir für später aufhebe... falls mich aber jemand dafür angemessen bezahlen will kann ich es vorziehen. Falls die NSA oder GCHQ die Besteller und Anwender sind verzichte ich da auch gerne auf die Erzwingung von HTTPS.

Jörg Reinholz