AW: Login-System für Webseite
Jetzt kommt es halt drauf an, auf was für nem System Du das ganze umsetzen willst, also Win-Server oder Unix-Server,
da es da auch noch tonnenweise Stolpersteine gibt...
Stolpersteine gibt es dabei eigentlich nur, wenn man bestimmte Module bzw. Funktionalitäten einsetzen möchte. Unter anderem Memcached oder Redis (wobei es bei Redis mittlerweile auch eine Windowsversion gibt, die von MS selbst gewartet und verteilt wird). Aber in der Regel sind PHP Projekte auf verschiedenste Server übertragbar. Egal ob Windows, Linux oder anderen Unixoiden. Apache, NGINX, Lighttpd, Mongoose, IIS ... Klappt eigentlich immer ohne Probleme.
Zum verlinkten Tutorial: Es sind solide Basics. Aber leider für die heutige Zeit nicht wirklich mehr ausreichend. Wenn dein Projekt ausschließlich in einem kontrollierten Intranet verwendet wird, dann kann man es so lassen. Sobald es allerdings über das gesamte Internet erreichbar sein soll, dann ist diese rudimentäre Umsetzung etwas mager.
1. Alle Formulare, die sich ohne Zugriffsrechte ausfüllen und abschicken lassen, sollte man gegen Bots absichern (Basis wäre eine CSRF-Protection wie im folgenden beschrieben). Dazu musst du es erzwingen, das dein Formular (in diesem Fall die Registrierung) auch aufgerufen wurde und nicht einfach nur die Daten direkt per HTTP-Request an das Target-Script gesendet werden. Das bedeutet also, das jeder Benutzer, egal ob registriert und eingeloggt oder nicht, eine Session bekommt. Innerhalb der Sessiondaten kannst du definieren, ob es sich um eine logged-in Session handelt oder die Session noch ausgeloggt ist. Im Zuge dessen erzeugt man beim Aufruf des Formulares einen temporären Schlüssel, der als Hidden-Inputfeld ins Formular eigetragen sowie in die Session geschrieben wird. Dieser wird beim absenden des Formulares wieder an den Server gesendet und mit dem, der in die Session geschrieben wurde, verglichen. Stimmt dieser, wurde das Formular regulär aufgerufen und die Daten können verarbeitet werden. Ansonsten wirft man eine Fehlermeldung und per Header einen passenden Statuscode zurück. Desweiteren sollte man beim Aufruf auch einen Timestamp in die Session eintragen und vor dem auswerten prüfen, ob zwischen Aufruf und Verarbeitung eine gewisse Zeit verstrichen ist. Bei einem 3-Zeiler wie diesem Formular sollte die Differenz in der Regel mehr wie 5 Sekunden betragen. Makrobots füllen solche Formulare in wenigen Millisekunden aus.
2. Die Password-Hash Bilbliothek von PHP ist so designed, das sich deine Software was die Verschlüsselung angeht so gut wie von selbst auf dem neuesten Stand hält. Und genau deswegen ist diese vereinfachte Nutzungsweise etwas ungünstig. Denn so wie in dem Tutorial wird es dazu führen, das es unterschiedlich gehashte Schlüssel in der Datenbank gibt. Es gibt noch eine Rehash-Funktion, mit der man prüfen kann, ob ein Hash noch dem aktuellen Standard entspricht. Wenn dem nicht so ist, sollte man das eingegebene Passwort beim Login direkt neu verschlüsseln und speichern, damit auch so viele wie möglich mit dem aktuellsten Standard-Algorithmus gehasht werden. Wenn man diese nicht einsetzen will, dann sollte man die Parameter der Hash-Funktionen manuell setzen.
3. Es fehlt noch ein Flood-Schutz. Hashing sowie Stringfunktionen erzeugen mehr Rechenlast als überwiegend Zahlenbasierte einfache Funktionen. Gerade die Hash-Bibliothek zielt auf einen erhöhten Kostenfaktor bei der Rechenleistung ab. Man sollte also bei zu vielen Zugriffen auf solche Scripts in kurzer Zeit die Zugriffe ohne intensiverer Verarbeitung abbrechen. Wenn man zum Ziel von DoS-Attacken wird, ist die einfachste Möglichkeit, den Server zu überfordern, ihn zum ständigen Hashen/Verschlüsseln zu zwingen. Das Loginscript ist die Ideale Basis für solche Angriffe. Man benötigt nur einen gültigen Nutzernamen und schon kann man mit genügend Requests den Server in die Knie zwingen. Die CSRF-Protection ist ein Anfang. Allerdings lässt sich das Loginscript nur schwer auf Zeit prüfen, da sich bei gespeicherten Zugangsdaten im Browser die Zeit zum ausfüllen des Formulares erheblich beschleunigen lassen und damit valide Benutzer beeinträchtigt werden könnten, wenn man einen zu großen Offset wählt. Deswegen sollte man hier noch zusätzlich einen Flood-Schutz einsetzen, um bei Makro-Bots die versuchen, DoS auf das Formular zu feuern, ab dem X-ten Aufruf in sehr kurzer Zeit einfach ein Bad-Request zurückwerfen.
Noch dazu gibt es einen Schönheitsfehler in dem Tutorial: Anstatt Trim bei jeder Nutzung der Daten zu verwenden, sollte man Trim für jedes Datenstück nur einmal nutzen, das Ergebnis in eine Variable schreiben und dann mit diesen weiterarbeiten. Das reduziert Rechenlast. Stringfunktionen sind in der Regel immer etwas rechenintensiver.
Ich habe gerade leider keine Links oder Tutorials für das ganze parat. Aber wie gesagt, deckt das verlinkte Tutorial nur die absoluten Basics ab und sollte meiner Meinung nach nicht mehr 1 zu 1 für eine Internetseite verwendet werden.
.gif "sm_B-) :-)")
.gif "sm_=) =)")
