User Login System

Ich kann mir nicht vorstellen, dass es für sowas ein out-of-the-box-Skript gibt. Allein das Übertragen der Session-Daten als URL-Parameter, falls Cookies nicht unterstützt werden, wirkt sich doch schon auf jeden (!) einzelnen Link innerhalb deiner Anwendung aus. Sämtliche Benutzerformulare müssen in die Anwendungsoberfläche integriert werden. Ich kann dir eine Liste mit Punkten angeben, die du bei der Implementierung eines solchen Systems beachten musst (z.B. Session nicht an eine IP, sondern besser an ein /24-Subnetz binden: Es gibt immer noch einige Load-Balancing-Proxys da draußen (einer davon steht bei meinem Brötchenfinanzierer), bekannt wurde das Problem z.B. durch AOL). Aber ein fertiges System halte ich nicht für praktikabel. Außerdem solltest du bei so einem kritischen Teil auch gut bescheid wissen, wie er funktioniert, um ihn nicht falsch zu verwenden oder Fehler schnell beheben zu können. (Wenn die Kennwort-wiederherstellen-Funktion Zugang zu allen Konten ermöglicht, möchtest du vielleicht nicht erst zwei Wochen auf ein Update des „Herstellers“ warten…)

ich würde so ein System unter die Lupe nehmen ohne Ende.
# Ip Subnetz ist bekannt, das Problem mit AOL hatten viele Foren.

ich suche eigentlich nur ein "Gutes" um eine Basis zu haben und daran anzuknüpfen.

Schau dir doch mal den UNB-Code an. In der Datei unb_lib/session.lib.php sind alle wesentlichen Funktionen zur Session-Verwaltung zu finden. Dass die Session-ID in URLs eingebaut wird, übernimmt die Funktion UnbLink in der Datei unb_lib/common.lib.php. Der Abschnitt "case 'setuser':" in der Datei forum.php implementiert das Wechseln der Identität (Login/Logout).
Link: Download - Unclassified NewsBoard Forum
Quelltext-Dokumentation: Index

cool, das sieht interessant aus, vielen Dank!

/me studier

ich wäre an so einer liste interessiert.
das mit dem 24-subnetz ist mir neu, was genau ist das?
könntest du vlt. kurz darstellen, wie man die ip inkl. 24-subnetz validiert.
ich habe schon in deinen code geschaut, werde aber nicht wirklich schlau.

lg

Ich schreib das die nächsten Tage mal zusammen.

Nur kurz vorab: Der IP-Subnetz-Vergleich befindet sich in unb_lib/session.lib.php, da wo „SessionNetMask“ vorkommt. Dadurch werden von der 32 Bit langen IPv4-Adresse nur die ersten bspw. 24 Bit verglichen.

vielen dank, dass du die liste zusammenstellen möchtest.

ich schau mir am WE die session.lib.php genauer an.

Hier eine schnell reingehackte Liste - nicht von besonderer Artikelqualität, stellt aber alles dar, was mir zu dem Thema einfällt. Viel Spaß beim Lesen.

* Alle Zugriffe auf das System müssen einmal durch die Session-Prüfung laufen. Es bietet sich an, diese Funktion zentral zu implementieren und im Rahmen der Programminitialisierung auch zentral aufzurufen.

* Sessions benötigen ein Timeout. Wird die Session eine bestimmte Zeit nicht verwendet, z.B. 30 Minuten, sollte sie verfallen. Kommt später nochmal jemand mit dieser Session-ID im Session-Cookie oder der URL an, darf er daraus keine Rechte mehr beziehen. Konkret muss beim Seitenzugriff festgestellt werden, dass die Session abgelaufen ist, um die entsprechenden Session-Variablen gelöscht werden. Direkt im Anschluss sollte dem Benutzer die Möglichkeit gegeben werden, sich mit Auto-Login-Cookies sofort wieder anzumelden, wodurch der Benutzer von der ganzen Aktion effektiv gar nichts mitbekommt, wenn er den automatischen Login mit (persistenten) Cookies aktiviert hat. Damit der letzte Zugriff immer korrekt gespeichert wird, kann man z.B. bei jedem Zugriff einen Timestamp in der Session speichern, dann hat man ihn gleich da, wenn man die Session prüft.

* Session an die IP-Adresse binden (siehe auch nächster Punkt). Dadurch wird das Session hijacking nahezu unterbunden. Das bedeutet, die Session-IDs, die u.U. in der URL übertragen werden, sind für andere Benutzer wertlos. Wenn jemand einen Link veröffentlicht, der noch diese ID enthält, ist das weit weniger gefährlich, als wenn jeder diese ID verwenden könnte. (Als URL-Parameter sind keine besonderen Kenntnisse nötig, ein Klick genügt, um die Identität (Session) zu übernehmen.)

* Session nicht an eine IP, sondern besser an ein /24-Subnetz binden: Es gibt immer noch einige Load-Balancing-Proxys da draußen (einer davon steht bei meinem Brötchenfinanzierer), bekannt wurde das Problem z.B. durch AOL. Diese Proxies verteilen die HTTP-Anfragen auf mehrere Ursprungs-IP-Adressen, für den Webserver sieht es aus, als kämen sie von verschiedenen Rechnern. Normalerweise liegen alle verwendeten Adressen in einem /24-Subnetz (d.h. die ersten 24 Bit = 3 Zahlen ändern sich nicht).

* Die Kennwort-Vergessen-Funktion ist i.d.R. für anonyme Benutzer zugänglich. Üblicherweise wird dabei ein neues Kennwort generiert und an die bekannte E-Mail-Adresse des Benutzers geschickt. Allerdings sollte das Kennwort nicht sofort auf Zuruf geändert werden - es könnte sein, dass der Benutzer grad seine Mails nicht liest oder lesen kann und nicht damit rechnet, dass irgendwer sein Kennwort verändert hat. Hier bietet sich das "Double-Opt-In"-Verfahren an: Zuerst wird dem Benutzer eine Bestätigungsanfrage geschickt, am besten ein Weblink, auf den er klicken muss, um die eigentliche Aktion (Kennwort generieren, ändern und mailen) auszuführen. Tut er das nicht (weil er es nie angefordert hat), kann er diese Nachricht getrost ignorieren.

* Damit das Programm auch ohne Cookie-Unterstützung des Browsers läuft, muss die nötige Session-ID in der URL als Parameter übertragen werden. PHP bietet dafür Funktionen an, auf die ich mich aber nicht verlasse. Für meine Zwecke hab ich deshalb eine zentrale Programmfunktion verwendet, die alle Web-Links zusammenbaut. Im einfachsten Fall hängt sie je nach Bedarf einfach nur die Session-ID an oder nicht. Ein Beispiel ist die UnbLink-Funktion im UNB (siehe oben). Die hat zusätzlich die Optimierung, dass bei anderen vorhandenen Cookies das PHP-eigene Auto-Sensing der Cookie-Unterstützung umgangen und zu keiner Zeit die Session-ID an die URL gehängt wird.

* Die Auto-Login-Cookies enthalten zwangsläufig die Benutzer-ID und das Kennwort in irgendeiner Form. Man kann (sollte) das Kennwort irgendwie verschlüsseln, ein Hash tut's für den Zweck auch, damit es zumindest schonmal nicht klar lesbar ist. Es muss aber jedem klar sein, dass man Cookies problemlos auf anderen Rechnern installieren kann, um sie dort weiterzuverwenden. Man kann sich also mit geklauten Cookies auch anmelden! Eine symmetrische Verschlüsselung oder ein Hash über das Kennwort und einen zusätzlichen Zähler, bei dem das zusätzliche Geheimnis jeweils nur auf dem Server bekannt ist, bieten dem Administrator die Möglichkeit, alle herausgegebenen verschlüsselten oder gehashten Kennwörter auf einmal ungültig zu machen. Wurde ein Fall festgestellt, in dem diese Kennwörter, z.B. durch eine XSS-Lücke der Webseite, zugänglich gemacht werden konnten, kann man alle potentiell geklauten Kennwörter ab diesem Zeitpunkt für ungültig erklären und so weiteren Schaden durch Missbrauch der geklauten Kennwörter abwenden. (Bis zu diesem Zeitpunkt funktionieren die Kennwörter aber natürlich noch.) Das zwingt zwar einmalig alle Benutzer dazu, sich neu einzuloggen, das das Auto-Login-Cookie ja ungültig ist, aber das ist besser, als allen Leuten klarzumachen, dass sie ihr Kennwort ändern sollten.

* Das Kennwort bzw. die Authentifizierungsdaten sollten nicht in der Server-Session gepsiehcert werden, um sie bei jedem Seitenzugriff erneut zu prüfen. Es ist ausreichend sicher, stattdessen nach erfolgreicher Prüfung ein Feld in der Session zu speichern, dass die Session authentifiziert wurde. Die Benutzer-ID sollte man natürlich noch speichern, damit man weiß, wer da überhaupt dran ist. Nur das Kennwort nicht, damit man es nicht auf dem Server auslesen kann. (Wer weiß, wo die Session gespeichert wird und wer sie alles lesen kann...) Dieses Flag muss beim Ausloggen (manuell oder automatisch) natürlich gelöscht werden, um die Session als "nicht eingeloggt" zu markieren.

* Bindet man die Session nicht an eine IP, sollte man keinesfalls direkt von Seiten der eigenen Anwendung auf fremde Webseiten verweisen. Enthält die aktuelle Seite die Session-ID als Parameter, wird sie als Referrer an den Zielserver übertragen, der die Daten dann zum Session Hijacking verwenden kann. Dazu werden üblicherweise Dereferrer verwendet. Eine Beschreibung findet sich hier: FAQ - Unclassified NewsBoard Forum

* Die Benutzerkennwörter sollten auf dem Server nicht im Klartextgespeichert werden. Prinzipiell ist es zwar nicht schädlich, da sowieso niemand Zugriff darauf haben sollte, aber es bietet einerseits eine weitere Schutzschicht, sollte der Server kompromittiert werden und die Daten offenlegen. Außerdem verwenden manche Leute das gleiche Kennwort an mehreren Stellen. Da der Admin üblicherweise DB-Zugang hat, kann er sich so u.U. ohne weiteres an anderen Systemen anmelden, an denen er nichts verloren hat. Es ist gut, die Kennwörter als Hash zu speichern (md5, sha1, sha256, ...). Eine Beschreibung der Hash-Funktionen und deren besonderer Eigenschaften steht im Lexikon. Ein interessantes Verfahren ist auch Keyed MD5: Die Formel dafür ist in etwa md5(md5(kennwort) + salt), die Verarbeitung ähnlich wie bei sha1. Der Clou an der Sache ist der, dass es keine eindeutige Abbildung des Hashes gibt, der salt ist zufällig gewählt. Außerdem müsste man den md5-Hash dann zweimal knacken... Weitere Hinweise müsste Google liefern, evtl in Verbindung mit IBM.

* Es ist vielleicht keine schlechte Idee, die Funktionen zum Erzeugen und Prüfen eines Kennworts zentral zu implementieren. So kann man ohne großen Aufwand das Verschlüsselungs-/Hashverfahren der Kennwörter ändern. Hier muss man ggf. nur auf die bereits vergebenen Kennwörter achten, die normalerweise nicht auf das neue Verfahren konvertiert werden können. Ein kurzer Identifier im gespeicherten Kennwort kann hier Aufschluss geben, welche "Version" des Kennwortverfahrens verwendet wurde. Bei md5 und sha1 lässt sich aber z.B. auch die Länge das Hashes unterscheiden (wenn ich mich jetzt nicht sehr irre). U.U. könnte man sich überlegen, das Kennwort im Moment der Anmeldung (also dem einzigen Moment, wo das Programm das Klartext-Kennwort sieht) im neuen Verfahren in die Datenbank zurückzuschreiben, falls das Verfahren mittlerweile geändert wurde. So kann dem Benutzer das Neusetzen des Kennworts abgenommen werden, wenn z.B. das neue Speicherverfahren für Kompatibilität mit einer zweiten Anwendung benötigt wird (ein Login für mehrere Systeme, die auf die gleiche DB zugreifen).

* Es gelten die üblichen Regeln sauberer Programmierung, hier im Speziellen für PHP: Keine uninitialisierten Variablen verwenden, alle Eingaben auf formale und inhaltliche Richtigkeit prüfen, auch mit völlig unerwarteten Benutzereingaben rechnen. Generell kann man keine Information, die irgendwie vom Benutzer stammen könnte, vertrauen! Nicht $_GET, nicht $_POST, nicht $_COOKIE und nicht $_FILES. $_REQUEST ist in dieser Liste implizit enthalten. Passt auf NUL-Zeichen (\0) auf, die vertragen manche PHP-Versionen nicht immer. Am besten gleich zu Beginn komplett rausfiltern. Siehe UNB, common.lib.php, "Global data initialisation". Dort stehen übrigens noch ein paar Tipps, wie die Daten für alle PHP-Umgebungen zuverlässig aufbereitet werden (u.a. von PHP fürsorglich eingefügte \ wieder rauswerfen, die kann dort niemand gebrauchen, der weiß, was er tut).

* Mehrere Versuche, sich mit dem falschen Kennwort anzumelden, sollten erkannt und behandelt werden. Ich denke, es ist am besten, eine zufällige Zeit im einstelligen Sekundenbereich zu warten (Verzögerung), und zwar bereits ab dem ersten Fehlversuch. Auch wenn das Kennwort später korrekt eingegeben wird, sollte verzögert werden. So muss der Angreifer immer auf die Antwort warten, wenn er wissen will, ob er das richtige Kennwort gefunden hat. Die Erkennung einer Wiederholung erfordert natürlich, den Rechner ohne eine Anmeldung identifizieren zu können. Eine IP-Adresse leistet hier sicherlich gute Dienste.

* Um das Verfahren des Passwort Raten zu erschweren, sollte ab einer gewissen Anzahl Versuche still alles abgelehnt werden - auch das richtige Kennwort. Sollte das richtige Kennwort ab dem 10. Versuch in kurzer Zeit noch nicht dabei gewesen sein, handelt es sich bestimmt um einen Angriff. Selbst wenn der Angreifer das richtige Kennwort erraten sollte, dürfen wir ihn dann nicht reinlassen, ihm aber auch nicht sonstwie mitteilen, dass das das richtige Kennwort ist, sonst kommt er später einfach nochmal damit zurück. Ein Türsteher würde auch niemanden reinlassen, der 20 Mal das falsche Kennwort genannt hat - selbst wenn er plötzlich das richtige nennt, da er offensichtlich nur geraten hat.

^ @zum letzten Punkt Vorsicht.
bei uns werden die Einloggversuche je nach IP limitiert.
werden die nach Account limitiert könnte eventuell jemand Deinen Account stilllegen, indem er unnötig viele Passwort Anfragen an Deinen Account sendent.

vielen Dank für die sehr sehr gute Liste!

Ja, Accountname und IP (oder Subnetz) wären gut, um wiederholte Loginversuche zu erkennen.

Ich möchte der Vollständigkeit halber noch anmerken, dass im UNB, das ich bereits als Referenz angegeben habe, nicht alle dieser Punkte exakt so umgesetzt sind, was z.T. mit dem Codealter oder Architekturentscheidungen zu tun hat.

Also etwas, was ich dir ans Herz legen könnte, wäre das Redaxo Framework. Bietet mit dem Addon "Simple User" in etwa die aufgezählten Anforderungen. Mal reinschauen:

REDAXO - Content Management System [CMS] - Kostenlos - Frei - PHP - MySQL - Open-Source | Simple To Use | www.redaxo.de