Welches ist das beste(sicherste) Loginsystem

[masterofeye]

Hallo an die Community

Ich arbeite immer noch an meiner Seite *puh*. Naja und nun kommt das Loginsystem dran. Ich hab schon mal kurz unter php-q gelesen und von mehreren Lösungen erfahren mit Sessions aber ist das die einzige Möglichkeit ? Und welche denkt ihr ist ne gute Lösung ?

MFG

Masterofeye

 

[pamax]

Hi,

bei einem Login-System hast du ja eigentlich nur die Wahl zwischen Cookies und Sessions. Bei Sessions differenziert man noch etwas. Es gibt zum Einen Sessions die in Cookies gespeichert werden und zum Anderen welche die per Url übergeben werden. Der Vorteil von Sessions, die per Url übergeben werden, ist, dass wenn der User Cookies disabled hat, trotzdem eingeloggt bleibt.Wenn der User eine längere Zeit eingeloggt bleiben soll(also wenn er mal eine halbe Stunde inaktiv war), musst du Cookies nehmen.

pMx

 

[mAu]

[...]
Wenn der User eine längere Zeit eingeloggt bleiben soll(also wenn er mal eine halbe Stunde inaktiv war), musst du Cookies nehmen.

pMx

Das ist meines Wissens so nicht ganz richtig. Denn ist die session.lifetime auf eine entsprechende Dauer festgelegt und schließt der User das Browserfenster nicht, wird die Session nicht verloren gehen. Sobald aber das Browserfenster geschlossen wird, geht auch die Session flöten (sollte kein Cookie gesetzt worden sein).

 

[GiFt-ZwErG]

Hi,

bei einem Login-System hast du ja eigentlich nur die Wahl zwischen Cookies und Sessions. Bei Sessions differenziert man noch etwas. Es gibt zum Einen Sessions die in Cookies gespeichert werden und zum Anderen welche die per Url übergeben werden. Der Vorteil von Sessions, die per Url übergeben werden, ist, dass wenn der User Cookies disabled hat, trotzdem eingeloggt bleibt.Wenn der User eine längere Zeit eingeloggt bleiben soll(also wenn er mal eine halbe Stunde inaktiv war), musst du Cookies nehmen.

pMx

Der Nachteil an der URL-Variante ist auch, dass wenn du auf externe Seiten verlinkst und diese dort eine Statistik mit Refererauswertung haben, dann sehen die die komplette URL inkl. SessionID und "könnten" mit dieser ID auf deiner Seite ohne Probleme die Rechte des Users erlangen der auf den externen Link geklickt hat.
Wenn du Cookies benutzt ( für die Sessions ) dann kann es passieren dass einem deiner User ( evtl nen Admin oder ein Mod ) der Cookie bzw der Inhalt geklaut wird. Und somit ist die SessionID dem Angreifer bekannt und der muss sich dann nur noch ein Cookie mit der SessionID des Admins, Users oder Mods setzen und hat die Rechte von dem.
Genau an diesen ganzen Problemen und Sicherheitsrisiken hänge ich momentan. Es gibt einen Thread von mir in dem das behandelt wird. Dort ist auch eine Lösung eines Users aus dem Forum, der mir das Prinzip seines Systems per PM geschickt hat, dabei.
Sein System ist sicherer als jedes andere was ich bis jetzt kenne. Es hat nur den Haken, dass es nicht funktioniert wenn der User Cookies disabled hat. Genau dass ist auch mein Problem.
Ich bin dabei eine eigene Sessionfunktion zu schreiben die alles genau so macht wie die PHPSessionverwaltung aber den User anhand der IP verifiziert und mit der DB abgleicht. Wenn der User ( die IP ) nicht mit seinem Hash ( der Useragent in MD5 ) übereinstimmt, dann wird der Eintrag und die Sessiondaten auf dem Server gelöscht und neu angelegt.
Die Chance dass jemand die IP eines anderen bekommt ( nach einem 24 Disconnect ) und dann den gleich User-Agent hat und auf die Seite geht ist sehr gering. Und die Einträge in der DB haben auch eine Verfallszeit.
Das ist mein theoretisches Loginsystem wo ICH sagen würde, dass ist sicher und universell ( cookies disabled usw ).
Ich müsste evtl noch testen wie das mit Proxys harmoniert. Da ein Proxy ja die IP und den User-Agent des "richtigen" Clients verschleiern bzw modifizieren.
Aber dass kann ich erst machen wenn das System fertig ist.

Ich hoffe ich konnte dir ein bisschen helfen


Schönen Abend noch.
MFG
Sandro



EDIT:

@mAu:

Wenn der Browser geschlossen wird, wird der Sessioncookie gelöscht.
Wenn der User dann auf die Seite geht wird eine neue ID und ein neuer Cookie gesetzt.

Wenn man die SessionID@URL nutzt, ist die Session solange verfügbar wie die Zeit auf dem Server eingestellt ist ( Session.Lifetime )

MFG

 

[Wolfsbein]

Die Sessionmoeglichkeit ist, sauber programmiert, das Sicherste. Und es gibt _kein_ Problem mit Usern ohne Cookies. Das merkt PHP selber und haengt an die URL dann die Session-ID an. Einzig bei komplizierten mod_rewrite Basteleien musst du aufpassen.

 

[GiFt-ZwErG]

Die Sessionmoeglichkeit ist, sauber programmiert, das Sicherste. Und es gibt _kein_ Problem mit Usern ohne Cookies. Das merkt PHP selber und haengt an die URL dann die Session-ID an. Einzig bei komplizierten mod_rewrite Basteleien musst du aufpassen.

Und dann gibt es immer noch das Problem mit dem SessionID Diebstahl... sobald die ID bekannt ist, kann JEDER die Rechte des Sessioninhabers übernehmen...
Da werden keine Kontrollen mehr durchgeführt ob der Client des wirklich der ist, der die ID erstellt hat.

 

[Gumbo]

Beide Methoden – ob Daten nun per Cookie oder URL übergeben werden – sind ja nur Übertragungsmethoden. Was die Sicherheit dieser angeht, liegt die Cookie-Methode der URL-Methode etwa eine Nasenlänge voraus. Beide Methoden haben ihre Vor- und Nachteile und ihre unterschätzten Schwachstellen, die leider häufig außer Acht gelassen werden.

Die Frage ist also eher, welche Daten übertragen werden sollen/müssen, wozu der Server diese Daten benötigt und wie er sie verarbeitet.

Nehmen wir das Beispiel der PHP-Sitzungs-ID: Die Sitzungs-ID dient der Identifizierung der Sitzung und damit auch der darin gespeicherten Daten. Übertragen wird nur die Sitzungs-ID, die also quasi als Schlüssel zu den Daten dient. PHP akzeptiert aber leider im normalen Zustand jegliche synaktisch korrekte Sitzungs-ID. Eine weitere Validierung findet nicht statt. Dies hat den Nachteil, dass jeder, der diese Sitzungs-ID besitzt, auch die in der Sitzung gespeicherten Daten nutzen kann – auch Fremde. Und genau das ist die Schwachstelle der nativen Sitzungsverarbeitung, die ausgebessert werden sollte.

 

[Dennis Wronka]

Da ich ja zur Zeit daheim keine Internetverbindung habe hab ich mich mal wieder mit meiner Website und den dafuer eingesetzten Techniken befasst.

Meine Sessions laufen ja bereits von Anfang an sowohl mit als auch ohne Cookies, bei der ersten Verbindung wird geprueft ob Cookies angenommen werden (siehe Ueberpruefung von Cookies und JavaScript mit PHP) und dies in der Datenbank festgehalten.

Nun ist es ja so, dass so eine SessionID (ob nun per URL oder Cookie uebergeben spielt dabei keine Rolle) gestohlen werden kann. Um das zumindest ein wenig einzudaemmen (ganz verhindern kann man es eh nicht) hab ich mir eine eigene Session-Verwaltung in Form einer Klasse geschrieben. Dabei gehoeren zur Identifikation einer Session eben nicht nur die SessionID, sondern eben auch die IP und der User-Agent. Es ist mit der Klasse theoretisch also auch moeglich, dass eine SessionID doppelt vergeben wird, eben an verschiedene Clients. Natuerlich ist das kein hundertprozentiger Schutz, aber wohl wesentlich besser als nur mit der SessionID zu arbeiten.

Da mir auch nie gefallen hat, dass die Session-Dateien immer so lang auf dem Server liegen bleiben hatte ich bereits eine eigene Garbage-Collection welche alten Session-Dateien wieder loescht.
Da dies unter Umstaenden zu Problemen mit dem SafeMode fuehren koennte nutzt meine Klasse keine Session-Dateien sondern speichert die Session in der Datenbank, dank meiner Klasse MultiSQL wahlweise in MySQL, PgSQL oder MSSQL.
Das wiederum macht es sehr einfach abgelaufene Sessions zu loeschen und sorgt auch fuer ein wenig mehr Sicherheit fuer den Fall, dass mal jemand zufaellig /tmp ausliest, welches ja normalerweise die Heimat der Session-Files ist. Obwohl diese zusaetzliche Sicherheit auch wirklich nur marginal ist, denn in der Regel steht ja nur die UserID in der Session.

Der naechste Schritt wird sein dies in meiner Seite einzubauen, mit $_SESSION kann ich ja dann nicht weiterarbeiten sondern muss eben ueber die Klasse gehen.

Zusaetzlich hab ich nunmal endlich dafuer gesorgt, dass einer der aeltesten Codes meiner Seite rausfliegt, und zwar der der die UserID und das Passwort als Hash in einem Cookie speichert, denn sowas ist einfach nicht zeitgemaess.
Nun werden zwei IDs mittels uniqid() erstellt, diese zusammengewuerfelt und per crypt() verschluesselt. Dieser Wert wird dann im Cookie und in der Datenbank gespeichert.

Ein weiterer Schritt zur Absicherung wird sein sicherzustellen, dass die SessionID ueber den Anfangs eingestellten Mechanismus (Cookies oder URL) reinkommt. Wenn also bei der ersten Verbindung erkannt wird, dass Cookies angenommen werden dann werden bei diesem Client auch nur Cookies zur Uebergabe der SessionID akzeptiert, und umgekehrt.

All diese Massnahmen zusammen sollten dann fuer einigermassen brauchbare Sicherheit meiner Sessions sorgen.

 

[Gumbo]

Ich finde die PHP-eigenen Sitzungsverarbeitung, also dass sämtliche Sitzungsdaten anschließend in der superglobalen $_SESSION-Variable verfügbar sind, gar nicht so übel. Auch das automatische Senden von Sitzungs-Cookies und das Anhängen der Sitzungs-ID ist eine hilfreiche Funktion, auf die ich nicht verzichten und aber die ich auch nicht unbedingt selbst nachbauen möchte.
Allein die Validierung der Sitzungs-ID stört mich. Und deshalb würde ich auch nur diese verbessern.

 

[Dennis Wronka]

Mich stoert $_SESSION und der ganze Rest auch nicht unbedingt, jedoch wollte ich die Session-Verwaltung eben in einer Klasse haben. Und da ich irgendwie Probleme hatte mit session_save_handler() die Methoden der Klasse als die Funktionen die die Session behandeln festzulegen hab ich etwas umgestellt. Ein grosser Unterschied ist es nicht wirklich.

Ich benutze auch weiterhin session_start() und ein/zwei andere Session-Funktionen, jedoch wird eben intern anders gearbeitet und eben anders auf die Session-Daten zugegriffen.