Sessionbasiertes Loginsystem

[tomtom]

Guten Abend,

undzwar war ich auf der Suche nach einem Sessionbasiertes Loginsystem und habe das hiergefunden. Dazu habe ich einige fragen:

1. ist das ein sicheres Loginsystem? Kann man das in die eigene Homepage einbauen?

2. Ich habe ca. 10 Benuzter in einer MySQL Datenbank mit Benutzername und Passwort (mit md5 verschlüsselt). Macht es Sinn, diese Zeile

// Benutzername und Passwort werden überprüft  
if($username == 'benjamin' && $passwort == 'geheim'){  
 $_SESSION['angemeldet'] = true;  
.  
.  
}

so um zu schreiben:

// Verbinfung zur Datenbank  
mysql_connect("localhost", "xxx", "xxx") or die ("Keine Verbindung");  
mysql_select_db("xxx") or die ("Keine Verbindung zur Datenbank");  
  
// Query  
$sql1 = "SELECT `pwd` FROM `login` WHERE `uname` = $_POST['user']";  
$result1 = mysql_query($sql1);  
  
while($row1 = mysql_fetch_object($result1)){  
 $pwd=$row1->pwd;  
}  
  
// Verbindung zur Datenbak schließen  
mysql_close();  
  
// Benutzername und Passwort werden überprüft  
if($passwort == md5(pwd)){  
 $_SESSION['angemeldet'] = true;  
.  
.  
}

Mir ist klar, das $passwort auch md5 verschlüsselt sein muss, bzw. das, was der user eingibt.

Würde das irgendwelche risiken mit auf sich ziehen? Was würdet Ihr mir empfehlen.

3. Ich hatte vorher immer die Session's mit in die MySQL Datenbank eingeschrieben, wenn sich einer eingeloggt hat und die authentifizierung so gemacht, dass ich geprüft hatte ob die session immernoch die gleiche ist. Falls ja, gings weiter, falls nicht ... anmeldeformular... Hier ist es ja etwas anders... Ist die Methode von "Euch" besser???

Viele Grüße und ein schönen Abend noch.
tomtom

[Jürgen]

3. Ich hatte vorher immer die Session's mit in die MySQL Datenbank eingeschrieben, wenn sich einer eingeloggt hat und die authentifizierung so gemacht, dass ich geprüft hatte ob die session immernoch die gleiche ist. Falls ja, gings weiter, falls nicht ... anmeldeformular... Hier ist es ja etwas anders... Ist die Methode von "Euch" besser???

Sie ist relativ ähnlich, nur recourcengünstiger, weil sie keinen db-connect produzieren muss.

Einen Nachteil sehe ich bei beiden Methoden.

Wenn Du 2 gleiche Systeme auf Deinem Server mit diesem Login-System laufen hast, bist Du mit einem Login in beiden Systemen eingeloggt ;-)

Grüzze, Jürgen

[tomtom]

danke für die Antworten,

kurz gesagt, kann ich das system benutzen, oder?

das mit dem session's die "entführbar" sind, ist mir schon klar. aber da ich sowieso wenige user habe und keiner von den irgendwie ahnung von sowas hat und nur einmal in der woche auf die seite zugreifen, sehe ich von meiner seite kein großes risiko.

gibt es einen einfachen beispiel mit der request-Methode wo auch mysql eingebunden wird?

vielen dank und ein schönen abend
tomtom

[Tom]

Hello,

gibt es einen einfachen beispiel mit der request-Methode wo auch mysql eingebunden wird?

Das habe ich Dir doch eben schon gepostet :-)

Viel mehr ist es ja nicht.
Verpack die relevante Sequenz in eine eigenständige Funktion oder Methode und schon bist Du fertig.

Usersanem sollte der Einfachheit halber einen Unique-Index erhalten. Damit wäre sichergestellt, dass es keine zwei Datensätze geben darf, auf die die Kriteren "Username und Passwort stimmen" zutreffen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[tomtom]

ok, danke....

ich habe es jetzt verstande....

gruß
tomtom

[tomtom]

hallo nochmals,

was ist damit gemeint?

$sql1 = "SELECT ìd, rights FROM logintable ".
          "WHERE uname  = '" . mysql_real_escape_string($_POST['user']) . "' " .
          "and password = '" . mysql_real_escape_string($_POST['password']) . "' ";

ist bei dir id die session id??? ich verstehe jetzt nicht den zusammenhang mit der request methode???

und was dann in der if anweisung bei "#1 angemeldet" stehen soll???

gruß
tomtom

[Jürgen]

hallo nochmals,

was ist damit gemeint?

$sql1 = "SELECT ìd, rights FROM logintable ".
          "WHERE uname  = '" . mysql_real_escape_string($_POST['user']) . "' " .

ist bei dir id die session id??? ich verstehe jetzt nicht den zusammenhang mit der request methode???

Tom meint damit die UserID und dessen Rechte aus einer wie immer auch genannten Usertabelle oder Tabellen.

Request=db-Zugriff.

und was dann in der if anweisung bei "#1 angemeldet" stehen soll???

Im Prinzip Deine Seite ;-)

Und bei Nicht angemeldet Deine Idee zur Fehlerbehandlung, also eine Meldung oder ein header:location oder sonst was Nettes .

Grüße, Jürgen

[tomtom]

Hallo,

aber wenn ich meine db-anfrage so wie in mein erstes posting mache, dann hätte ich ja auch eine request oder nicht???

// Query  
$sql1 = "SELECT `pwd` FROM `login` WHERE `uname` = $_POST['user']";  
$result1 = mysql_query($sql1);  
  
while($row1 = mysql_fetch_object($result1)){  
 $pwd=$row1->pwd;  
}  
  
// Verbindung zur Datenbak schließen  
mysql_close();  
  
// Benutzername und Passwort werden überprüft  
if($passwort == md5(pwd)){  
 $_SESSION['angemeldet'] = true;  
...  
}

das die sessions entführbar sind, ist klar ... aber wenn ich logout mache, zerstöre ich ja die session wieder.

"rights" brauche ich auch nicht...

wo ist denn jetzt der unterschied?

gruß
tomtom

[Tom]

Hello,

1. ist das ein sicheres Loginsystem? Kann man das in die eigene Homepage einbauen?

Es ist sessionbasiert und nicht requestbasiert, da die Authentifizierung nur einmal beim Eröffnen der Session vorgenommen wird. Das bedeutet auch, dass der Administrator einem User während seiner Session keine neuen Rechte zuweisen kann und ihn auch nicht rausschmeißen kann, ganz umständliche Varianten mal außer Aht gelassen.

Außerdem sind Sessions bei einigen Installationen leider auch einfach entführbar, sodass die Manipulationsmöglichkeit dann i.d.R. einfache ist, als bei einem requestbasierten System.

Besser wäre es also, gleich ein requestbasiertes System aufzubauen, in dem bei jedem Request die SQL-Abfrage durchgeführt wird:

[code lang=php]// Verbinfung zur Datenbank

$con = mysql_connect("localhost", "xxx", "xxx") or die ("Keine Verbindung");  ## [1]

mysql_select_db("xxx") or die ("Keine Verbindung zur Datenbank");      ## [1]

// Query

$sql1 = "SELECT ìd, rights FROM logintable ".
          "WHERE uname  = '" . mysql_real_escape_string($_POST['user']) . "' " .
          "and password = '" . mysql_real_escape_string($_POST['password']) . "' ";

$result1 = mysql_query($sql1);

if ($result1 and mysql_num_rows($result1) == 1)
{
    ## angemeldet
}
else
{
    ## Fehlerbehandlung
}

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jürgen]

Hi Tom,

ein paar Anmerkungen, die mir spontan einfallen.

Es ist sessionbasiert und nicht requestbasiert, da die Authentifizierung nur einmal beim Eröffnen der Session vorgenommen wird. Das bedeutet auch, dass der Administrator einem User während seiner Session keine neuen Rechte zuweisen kann und ihn auch nicht rausschmeißen kann, ganz umständliche Varianten mal außer Aht gelassen.

Warum sollte das so sein?
Neue Rechte=umständlich könnt ich noch nachvollziehen, aber rausschmeißen? Ist ganz easy. ;-)

// Query
  $sql1 = "SELECT ìd, rights FROM logintable ".
          "WHERE uname  = '" .

Hier würde ich ganz grundsätzlich casesensitiv arbeiten (Stichwort BINARY)

Und zu guter Letzt: Wie möchtest Du denn Username und Passwort von Seite zu Seite mitschleppen, wenn nicht über eine Session? Per Post oder Get?

Na, ich weiß nicht. Und über Session, dann kannst Du auch gleich den Login-Status übergeben.

Grüße, Jürgen

[Tom]

Hello,

Es ist sessionbasiert und nicht requestbasiert, da die Authentifizierung nur einmal beim Eröffnen der Session vorgenommen wird. Das bedeutet auch, dass der Administrator einem User während seiner Session keine neuen Rechte zuweisen kann und ihn auch nicht rausschmeißen kann, ganz umständliche Varianten mal außer Aht gelassen.

Warum sollte das so sein?
Neue Rechte=umständlich könnt ich noch nachvollziehen, aber rausschmeißen? Ist ganz easy. ;-)

Wie würde denn das Rausschmeißen eines bestimmten Users ganz einfach funktionieren, wenn das Login nur von einem Flag in der Sessiondatei abhängig ist?

Für ein fertiges requestbasiertes System gehören allerdings noch ein paar weitere Schritte dazu, wenn man nicht von der Sessiondatei alleine abhängig sein will. Beim Folgerequest (wenn man also schon angemeldet ist) werden ja die Logindaten nicht mehr übermittelt mittels POST.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jürgen]

Hi Tom,

Wie würde denn das Rausschmeißen eines bestimmten Users ganz einfach funktionieren, wenn das Login nur von einem Flag in der Sessiondatei abhängig ist?

OK, jetzt weiß ich, was Du mit "rausschmeißen" gemeint hast. SPERREN. Ich meinte indes wirklich "rausschmeißen". ;-)

Für ein fertiges requestbasiertes System gehören allerdings noch ein paar weitere Schritte dazu, wenn man nicht von der Sessiondatei alleine abhängig sein will. Beim Folgerequest (wenn man also schon angemeldet ist) werden ja die Logindaten nicht mehr übermittelt mittels POST.

Sondern?
Würde mich wirklich ganz aktuelle interessieren.

Grüße, Jürgen

[Tom]

Hello,

OK, jetzt weiß ich, was Du mit "rausschmeißen" gemeint hast. SPERREN. Ich meinte indes wirklich "rausschmeißen". ;-)

... weitere Handlungen unterbinden, und zwar nicht erst mit dem nächsten Login, sondern eben sofort, wenn es dem Administrator beliebt.

Sondern?

Im Moment habe ich jetzt gerade nicht die Nerven, die entwprechenden Threads hier im Archiv alle zusammenzusuchen. Ich werde aber morgen Abend mal schaun, ob ich die alle wiederfinde, sonst muss ich es alles nochmal schreiben...

Im Prinzip: Wenn keine POST-Daten zu User und Passort kommen, aber eine Session bekannt ist, in der Logintabelle nach der Session-Nummer suchen.

Zum Login ein Update der Sessionnummer und des "Lastclick-Timestamp" vornehmen für den Datensatz, bei dem Username und Passwort stimmen.

Dementsprechend zum Suchen der Sessionnummer auch mit einem Update vorgehen mit entsprechend intelligenter Where-Klausel.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Dementsprechend zum Suchen der Sessionnummer auch mit einem Update vorgehen mit entsprechend intelligenter Where-Klausel.

Einen der Threads habe ich schon gefunden:
http://forum.de.selfhtml.org/archiv/2008/4/t170126/#m1111727

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jürgen]

Im Moment habe ich jetzt gerade nicht die Nerven, die entwprechenden Threads hier im Archiv alle zusammenzusuchen. Ich werde aber morgen Abend mal schaun, ob ich die alle wiederfinde, sonst muss ich es alles nochmal schreiben...

Passt schon. keine Hektik. ;-)

Außerdem weiß ich dank Deiner Kurzanleitung jetzt schon in etwa, wie Du es meinst.

Deshalb eine Frage dazu: Mit Sessionnummer meinst Du die Session-ID? Und was ist an der sicherer als z.B. an $_SESSION['loginstatus']?

Grüße, Jürgen

[Tom]

Hello,

Passt schon. keine Hektik. ;-)

Das beruhigt mich.

Außerdem weiß ich dank Deiner Kurzanleitung jetzt schon in etwa, wie Du es meinst.

Deshalb eine Frage dazu: Mit Sessionnummer meinst Du die Session-ID? Und was ist an der sicherer als z.B. an $_SESSION['loginstatus']?

Es geht darum, das Kriterium für die Anmeldung aus der Session herauszubekommen und in die DB zu verlagern bzw. durch die Abfrage der DB per Request dann eben das Rausschmeißen oder Rechteändern zu ermöglichen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jürgen]

Es geht darum, das Kriterium für die Anmeldung aus der Session herauszubekommen und in die DB zu verlagern bzw. durch die Abfrage der DB per Request dann eben das Rausschmeißen oder Rechteändern zu ermöglichen.

Hi Tom,

ok. Akzeptiert.

Aber unabhängig vom Rechteändern und Rausschmeißen (was worklich sehr gut funktioniert...ich habe Dein System mal für mich umgesetzt: Ist das System ansonsten nicht genauso sicher/unsicher, wie das über eine einmal angemeldete $_SESSION['logstat']??

Grüße, Jürgen

[Tom]

Hello Jürgen,

Aber unabhängig vom Rechteändern und Rausschmeißen (was worklich sehr gut funktioniert...ich habe Dein System mal für mich umgesetzt: Ist das System ansonsten nicht genauso sicher/unsicher, wie das über eine einmal angemeldete $_SESSION['logstat']??

Wenn eine Session entführt werden kann, also auf die Sessiondatei auch durch Fremde zugegriffen werden kann, ist das Ganze sehr unsicher,w enn man nur auf die Sessiondatei baut. Es ist nur ein Erfahrugnswert, aber ein unerlaubter Zugriff auf die Datenbank ist bei allen von mir untesuchten Standardeinrichtungen sehr viel schwerer oder sogar unmöglich. Er setzt schließlich sowphl den Missbrauch (unerlaubten Zugriff) auf das Script meit den Verbindungsdaten, als auch auf das Auswertescript voraus, bzw. überhaupt Zugriff auf die Scripte.

Eine Änderung eines einzelnen Datenwertes in der Sessiondatei ist dagegen schon sehr leicht abzubulden. Ich würde mich freuen, wenn sich auch noch Andere an der Diskussion dazu beteiligen würden.

Es gibt außerdem auch in Scripten "sichere Formulierungen" und "unsichere Formulierungen". Das jetzt hier aus dem Stand zu diskutieren, schaff ich gerade nicht. Aber man kann in einem Script die Sciherheitsabfragen so formulieren, dass es nicht ausreicht, an einer einzigen Stelle einen einzigen booleschen Wert umzuschubsen, um die Manipulation durchlaufen zu lassen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jürgen]

Eine Änderung eines einzelnen Datenwertes in der Sessiondatei ist dagegen schon sehr leicht abzubulden. Ich würde mich freuen, wenn sich auch noch Andere an der Diskussion dazu beteiligen würden.

Hi Tom,

würde ich mich auch.

lassen wir den Thread malm "durchlaufen"...

...und schauen, welche Cracks sow as wirklich noch verfolgen und mitdiskutiern.

Ab "irgenwann" ist das erneute Post ja auch nicht mehr als Doppelposting zu werten ;-)

Jedenfalls sehr interessante Frage, wie ich (und Du) finden.

VG, Jürgen

[dedlfix]

Hi!

undzwar war ich auf der Suche nach einem Sessionbasiertes Loginsystem und habe das hiergefunden. Dazu habe ich einige fragen:

1. ist das ein sicheres Loginsystem? Kann man das in die eigene Homepage einbauen?

Bis auf die unnötige Umkopiererei am Anfang sehe ich nichts Auszusetzendes.

2. Ich habe ca. 10 Benuzter in einer MySQL Datenbank mit Benutzername und Passwort (mit md5 verschlüsselt). Macht es Sinn, diese Zeile
   so um zu schreiben:

// Verbinfung zur Datenbank

mysql_connect("localhost", "xxx", "xxx") or die ("Keine Verbindung");
mysql_select_db("xxx") or die ("Keine Verbindung zur Datenbank");

  
... or die() macht eigentlich nie Sinn. Sinnvoll ist es auch recht selten. Was kann der Nutzer dafür, dass deine Datenbank streikt? Nichts. Er braucht auch nicht zu wissen, dass sie das gerade macht. Er will an sein Ziel kommen. Was gibt es in dem Fall für Alternativen? Wenn du einen Shop betriebest, wäre es günstig, ihnen eine Bestellung per E-Mail vorzuschlagen, sonst kauft er noch woanders, was es zu vermeiden gilt. Was in deinem Fall für die Nutzer von Interesse ist, weiß ich nicht.  
  

> $sql1 = "SELECT `pwd` FROM `login` WHERE `uname` = $\_POST['user']";  
  
Abgesehen davon, dass mindestens noch ein Satz Anführungszeichen fehlen, fehlt augenscheinlich bei dir noch die Sensibilität für [Kontextwechsel](http://aktuell.de.selfhtml.org/artikel/php/kontextwechsel/). Du fragtest nach Sicherheit, und das Verständnis für Kontextwechsel ist ein wesentlicher Beitrag dazu. Und wenn du das Thema verstanden hast, weißt du, dass nicht nur die Anführungszeichen fehlen.  
  

> // Benutzername und Passwort werden überprüft  
> if($passwort == md5(pwd)){  
  
Falschrum. Vom eingegebenen Passwort des Benutzers musst du den Hashwert bilden und den mit dem bereis früher gehashten Wert im DBMS vergleichen.  
  

> Mir ist klar, das `$passwort`{:.language-php} auch md5 verschlüsselt sein muss, bzw. das, was der user eingibt.  
  
Ja, aber wie gesagt, das in der Datenbank ist es schon und muss nicht nochmal.  
  
  
Zum Rest sag ich jetzt mal nichts, das hat der Tom ja schon in Arbeit.  
  
  
Lo!