nicht angemeldet
Benötige *sicheres* Script für Loginbereich mit Sessions
Moin,
das Prinzip von Sessions ist mir bekannt. Das Prinzip eines Logins auch. Allerdings möchte ich Benutzername und Passwort in einer Datenbank ablegen und dafür ein Login entwickeln.
Nun könnte ich einfach mit Formularen und Variablen arbeiten... allerdings wäre das Ganze dann einfach zu knacken, indem man die Variablen, welche übergeben werden, manipuliert.
Hat also jemand mal ein kleines simples Beispiel für ein solches 'sicheres' Login? Wo man nicht einfach irgendwas manipulieren kann?
Wäre echt hilfreich, ich weiss nämlich nicht weiter!
-
Hallo strike,
Nun könnte ich einfach mit Formularen und Variablen arbeiten... allerdings wäre das Ganze dann einfach zu knacken, indem man die Variablen, welche übergeben werden, manipuliert.
Da liegt ein Denkfehler vor. Wenn Du am Anfang jeder Seite überprüfst, ob die Session zu einem gültigen User gehört, und sonst auf ein ganz normales HTML-Login-Formular verweist, wüßte ich nicht, welche Variablen man da böserweise manipulieren sollte. Du darfst nur nicht am Anfang der Seite eine Variable nehmen, die Du nicht initialisierst, z.B.
if(...überprüfung ob session gültig...)
{
$userok=1;
}
if($userok==1)
{
//inhalt anzeigen
}else
{
//redirect auf login
}Dann kan man an jede url einfach ein &userok=1 anhänge, und vorbei ist es mit dem Schutz. Aber das wird entweder durch ein $userok=0 am Anfang des Skripts beseitigt, oder in neueren php-Versionen durch register_globals=off in der php.ini.
Das einzige Sicherheitsrisiko, das bleibt, ist die Klartextübertragung von Username und Passwort über HTTP, wo immer jemand mitlesen kann. Das läßt sich durch HTTPS vermeiden. Bei der phplib gibt es auch einen Modus namens "Challenge-Response-Authentication", wo die Übertragung des Passworts im Klartext verhindert wird, das funktioniert aber nur mit Javascript.
Viele Grüße
Stephan -
Auch Moin!
das Prinzip von Sessions ist mir bekannt. Das Prinzip eines Logins auch. Allerdings möchte ich Benutzername und Passwort in einer Datenbank ablegen und dafür ein Login entwickeln.
Nun könnte ich einfach mit Formularen und Variablen arbeiten... allerdings wäre das Ganze dann einfach zu knacken, indem man die Variablen, welche übergeben werden, manipuliert.
Hat also jemand mal ein kleines simples Beispiel für ein solches 'sicheres' Login? Wo man nicht einfach irgendwas manipulieren kann?
Das Problem ist: Es gibt bei HTTP absolut keine Möglichkeit, einen "Login" im klassischen Sinne zu basteln. Es werden immer Krücken genommen.
Krücke Nr. 1 (auf jeden Fall zu bevorzugen): HTTP-Authentifizierung, auch bekannt als .htaccess-Methode (obwohl man das auch mit PHP hinkriegt).
Hierbei werden bei jedem Request, den der Browser an den Server schickt, immer Username und Paßwort mitgeschickt, also kann bei jeder Anfrage geprüft werden, ob diese Angaben gültig sind. Im Zusammenspiel mit HTTPS ist diese Methode ziemlich sicher, nur mit HTTP wäre eigentlich AuthType Digest zu empfehlen, weil dabei zumindest die Username/Paßwortangabe verschlüsselt wird, und am schlimmsten, weil unverschlüsselt ist Basic. Netscape 4 kann nur Basic, was Digest-Lösungen immer noch ausschließtKrücke Nr. 2: Sessions.
Dabei wird einmal per Formular Username und Paßwort an den Server gesendet. Als Gegenleistung wird dem Browser quasi ein String mitgeteilt (die Session-ID), der bei weiteren Anfragen immer wieder mitgesendet werden muß - wahlweise als Cookie, als URL-Parameter oder als verstecktes Feld in Formularen (mach PHP alles automatisch). Solange der Benutzer nicht die Logout-Funktion aktiviert hat und dieser String als ungültig beim Server bekannt gemacht wird, hat derjenige Zugriff, der den String kennt, auch wenn er Username und Paßwort nicht kennt.Sicher ist dabei eigentlich nur Methode 1, zumindest ist sie sicherer als Methode 2. Ich würde es also einfach damit probieren.
http://www.php.net/manual/de/features.http-auth.php lesen, wenn .htaccess nicht direkt etwas für dich ist.
- Sven Rautenberg
-
Auch Moin!
Guten abend!
Sicher ist dabei eigentlich nur Methode 1, zumindest ist sie sicherer als Methode 2. Ich würde es also einfach damit probieren.
Nur mal kuriositätshalber: wieso ist Methode 2 unsicherer als Methode 1? 100% Sicherheit gibt es sowieso nicht. (da stimmen wir ja überein) Aber eine Session-ID lässt sich Mathematisch gesehen nur sehr schwer fälschen (bis man eine gültige findet, dauert es sehr sehr lange ...). Hab' ich da was übersehen?
Grüße,
Christian
-
Moin!
Sicher ist dabei eigentlich nur Methode 1, zumindest ist sie sicherer als Methode 2. Ich würde es also einfach damit probieren.
Nur mal kuriositätshalber: wieso ist Methode 2 unsicherer als Methode 1? 100% Sicherheit gibt es sowieso nicht. (da stimmen wir ja überein) Aber eine Session-ID lässt sich Mathematisch gesehen nur sehr schwer fälschen (bis man eine gültige findet, dauert es sehr sehr lange ...). Hab' ich da was übersehen?
Ich persönlich sehe bei Sessions eigentlich zwei Probleme:
Erstens potentielle Datenlecks, indem die Session-ID in Referern auftaucht.
Zweitens dadurch, daß man meist einen selbstgestrickten Mechanismus entwerfen muß, dessen Sicherheit nicht unbedingt garantiert ist. .htaccess funktioniert einfach.
Die Frage ist: Welche Daten sollen gesichert werden? Denn je nach der Schwere der Folgen eines Einbruchs ist HTTPS unerläßlich, weil unverschlüsselte Daten abgefangen werden könnten.
- Sven Rautenberg
-
Hallo,
Ich persönlich sehe bei Sessions eigentlich zwei Probleme:
Erstens potentielle Datenlecks, indem die Session-ID in Referern auftaucht.
Ok, ich geb' mich geschlagen. Da muss man dann schon eine Seite dazwischen schalten, falls ein Link nach außen geht. (und das erfordert wieder Aufwand)
Zweitens dadurch, daß man meist einen selbstgestrickten Mechanismus entwerfen muß, dessen Sicherheit nicht unbedingt garantiert ist. .htaccess funktioniert einfach.
Das ist natürlich wahr. Und die Sicherheit eines solchen Systems liegt dann nicht im Konzept, sondern in der Implementierung. Und wenn die sich austricksen lässt, dann ist es aus mit der Sicherheit.
Die Frage ist: Welche Daten sollen gesichert werden? Denn je nach der Schwere der Folgen eines Einbruchs ist HTTPS unerläßlich, weil unverschlüsselte Daten abgefangen werden könnten.
Das sowieso.
Fazit: Die Gefahr, dass man was falsch macht, ist bei Sessions größer als bei HTTP-Authentication.
Grüße,
Christian
-
-
-