Moin!

Tach!

Richtig, das Thema ist notwendigerweise komplex. Deswegen würde ich alles weglassen, was auf die notwendige Komplexität noch unnötige draufsetzt.

In der Hinsicht sollte die Frage in den Raum geworfen werden, wie weit wir gehen wollen.
* Komplette Lösung?
* Nur ein Anriss?

Du kannst keine komplette Lösung in einem Artikel präsentieren, sonst hast du in nahezu jedem Teilaspekt, der für das Thema wichtig ist, zwei bis drei Aspekte, die davon ablenken.

Wenn du eine komplette Lösung anbieten willst, biete sie zum Download an. Viel Spaß bei der Pflege die nächsten Jahre (was leider, auch bei Code in Artikeln, ein grundsätzliches Problem ist, zu dem ich keine Lösung habe).

Was ist für ein aktuelles Login-System zwingend notwendig? Ein User muss sich neu anmelden können mit Username und Passwort, und er muss sich einloggen und dabei das Passwort geprüft kriegen.

Das ist der Stand der Dinge.

password_needs_rehash().
Oha! Das schafft einen völlig neuen Punkt und einen völlig neue Diskussionsbedarf:
* Das Passwort im Hintergrund schweigend neu hashen
* und/oder (auch zu diskutieren!)
* den Benutzer hinsichtlich des schwach gehashten Passworts warnen und ein neues eingeben lassen. Bitte auch an die Verwirrung der Benutzer und die "Kommerzköppe" denken.

Und natürlich das Prüfen des Passworts auf Komplexität
Woll. Das dann gleich mit.

Das Speichermedium für die User steht nicht im Mittelpunkt.
Hab ich gelesen. Mal sehen, was die anderen dazu sagen.

Die auszuliefernden Inhalte auch nicht.
Naja. Ohne den Schutz auch auf andere Dateien (Pics, Medien, Downloads) auszudehnen macht das nicht so viel Sinn - oder? Meinst Du das überhaupt?

Eine "komplette Lösung" müsste ja sinnvollerweise irgendwelchen Content anbieten, den nicht jeder sehen darf. Würdest du noch Usergruppen ins Thema hineinziehen, brauchst du sogar zwei unterschiedliche Inhalte. Und musst außerdem Dinge wie ACL oder RBAC erklären und implementieren (beides bietet allein schon Stoff für jeweils mehr als zwei Artikel, IMHO).

Die Fallback-Lösung für PHP-Versionen kleiner 5.5 ebenfalls nicht (das ist ein Einzeiler mit "Lad die Kompatibilitätslib runter und rufe am Anfang einmal require_once(libdatei.php) auf."). Das sind alles Themen für andere Artikel drumherum.

Hier bin ich ziemlich fest anderer Meinung und habe dafür nach meiner Meinung auch gute Gründe: Wir schreiben den Februar anno 2015. Viele haben in dieser Realität bei ihrem Hoster noch kein PHP 5.5 oder jünger. Ich halte es für keine gute Idee Skripte anzubieten, die bei denen (noch) nicht laufen. Das würde einen Ansehensverlust und eine Menge Rückfragen - nicht nur hier im Forum - nach sich ziehen.

Die Lib läuft bis runter zu PHP 5.3.7. Sie läuft deswegen nicht mit älteren Versionen, weil deren Crypt-Funktion kaputt ist!

Du willst auf kaputter Softwaregrundlage keine Reimplementierung relevanter Hashing-Algorithmen bauen. Es ist unmöglich, bcrypt nativ in PHP zu implementieren - der Laufzeitunterschied zur C-Variante wäre vermutlich recht hoch, was dazu zwingen würde, einen deutlich kleineren Kostenfaktor zu wählen - das gefährdet aber die Sicherheit. Dasselbe gilt für alternative Hash-Algorithmen.

Ich finde es sehr bedauerlich, dass man auf eine Plattform, deren offizieller Support bereits vor über einem halben Jahr endete (18. August 2014), immer noch mit Primärfokus Rücksicht nehmen soll. Wie sollen Entwickler lernen, mit den Möglichkeiten der neuen Versionen umzugehen und sie folgerichtig bei ihren Hostern auch einzufordern, wenn es niemand vormacht?

Abwärtskompatibilität ist kein Primärziel des Artikels, sondern eine Randerscheinung.

- Sven Rautenberg