Login Script Idee - Sicher?

[ComicKopf]

Hallo,

ich möchte ein Login-Skript auf einer Website einbauen, und habe da an folgendes gedacht:

//Datenbankverbdingung ist hergestellt

if(preg_match("/^[a-z0-9\ä\ü\ö\ß\# \.\-\_]{2,20}+$/i",$_POST["login"])){
   $read_ul="SELECT benutzernr,passwort FROM benutzer WHERE 
   nickname='".mysql_real_escape_string($_POST["login"])."' 
   AND passwort!='' LIMIT 0,1";
   $result_ul=mysql_query($read_ul);
   $range_ul=mysql_num_rows($result_ul);

   if($range_ul==1){
     $row_ul=mysql_fetch_array($result_ul);

     if(md5($_POST["login_p"])==$row_ul["passwort"] AND trim($_POST["login_p"])!="" 
       AND strlen(trim($_POST["login_p"]))<=25 
       AND strlen(trim($_POST["login_p"]))>=4){
         $_SESSION["bnr"]=$row_ul["benutzernr"];
     }
   }
}
                  
if(preg_match("/^[0-9]{1,10}$/",$_SESSION["bnr"]) AND $_SESSION["bnr"]>0){
  echo"Geschützter Bereich";
              
  //Anhand der "BNR" die Rechte der Person erfragen und dementsprechend Optionen anzeigen!
} 

Ich habe schon einiges zu diesem Thema gelesen, aber wollte mal meinen eigenen Code dazu vorstellen. Es wäre nett wenn ihr mir helfen könntet mein eigenes Beispiel zu verbessern.

Danke!

Gruß

[unset]

Bitte brich deinen Code um, ich habe keine Lust mit 22 Zoll immer noch vertikal scrollen zu müssen, um jede Zeile komplett lesen zu können. Desweiteren solltest du sprechende Variablennamen benutzen "$range_ul" versteht man nicht, wenn man es nicht selbst geschrieben hat. Außerdem solltest du vielleicht mit ein paar Worten erklären, was du da genau machst.

[AmicaNoctis]

Hallo,

Login Script Idee - Sicher?

Nein, sicher ist es nicht, wenn das Passwort im Klartext über die Leitung geht, es sei denn du nutzt bereits eine SSL-Verbindung dafür. Ohne SSL ist HTTP Digest Authentication eine sichere Variante. Warum immer Login-Formulare bauen, wenn man das gleich auf HTTP-Level machen kann?

Gruß,

Amica

[onemorenerd]

Wieso gehst du auf alle Variablen, sogar auf selbst erzeugte, mit preg_match() los?
Wieso prüfst du nicht gleich in der Query, ob der MD5-Hash vom Passwort stimmt?
Wieso muss der Benutzername noch weiter geprüft werden, wenn bereits feststeht, dass er mit dem Benutzernamen in der DB idetisch ist?

Also ingesamt ist der Ansatz zwar sicher, aber zu umständlich.

[ComicKopf]

Danke für die schnellen Antworten.

Sorry, dass ich den Code nicht umgebrochen habe. Werde in Zukunft darauf achten.

@onemorenerd:
Mit dem md5-Hash hast du recht. Ich habe die Abfrage so gestaltet, damit ich eine entsprechende Fehlermeldung anzeigen könnte. d.h. "Ja, Benutzer gefunden, aber das Passwort passt nicht."
Sonst würde sofort kein Datensatz gefunden werden.

Welche selbst erzeugten Variablen meinst du?

Was meinst du mit weiterer Prüfung des Benutzernamens? Ich prüfe vorher der BN überhaupt gültig ist und dann ob es einen entsprecheden Datensatz gibt. Kann man sich das sparen?

Du und Amica widersprecht euch jetzt in der Aussage, ob das sicher ist.
@Amica: Wie genau hast du das gemeint?

Gruß

[AmicaNoctis]

Du und Amica widersprecht euch jetzt in der Aussage, ob das sicher ist.
@Amica: Wie genau hast du das gemeint?

Wirklich sicher ist ein Login nur, wenn das Passwort verschlüsselt übertragen wird. Das ist nur der Fall, wenn das Login entweder per SSL erfolgt (wie bei den meisten großen Freemailern) oder wenn du HTTP Digest Authentication verwendest. HTTP Basic Authentication ist da auch nicht sicher, weil dort das Passwort zwar nicht im Klartext übertragen wird, aber trotzdem sehr leicht mit base64_decode ausgelesen werden kann.

Login-Formulare haben (das ist meine Privatmeinung) absolut keinen praktischen Sinn und dienen nur dazu, das Login schicker zu machen, als den Standard-Authentifizierungsdialog des jeweiligen Browsers. Sicherer sind sie jedenfalls nie.

[combie]

Login-Formulare haben (das ist meine Privatmeinung) absolut keinen praktischen Sinn und dienen nur dazu, das Login schicker zu machen,.....

Wie kommst du im "PHP als CGI Modus" an den Usernamen?

[onemorenerd]

Mit dem md5-Hash hast du recht. Ich habe die Abfrage so gestaltet, damit ich eine entsprechende Fehlermeldung anzeigen könnte. d.h. "Ja, Benutzer gefunden, aber das Passwort passt nicht."

Mit solch präzisen Fehlermeldungen erleichterst du aber Brute Force Attacken bzw. gibst Daten (die Existenz eines Benutzernamens) preis.

Welche selbst erzeugten Variablen meinst du?

Die Benutzernummer hat sich der User sicher nicht selbst ausgedacht. Sie wurde vom System erzeugt, z.B. per auto_increment. Sorge dafür, dass dein System nur valide Benutzernummern in die DB schreibt. Dann brauchst du sie nicht immer wieder zu überprüfen, wenn du sie aus der DB holst.

Was meinst du mit weiterer Prüfung des Benutzernamens?

Sorry, ich meinte nicht den Namen sondern das Passwort. Du holst den Datensatz aus der DB, der den eingegebenen Benutzernamen enthält. Später prüfst du noch, ob das Passwort dem aus dem DS entspricht UND nicht leer ist und zwischen 4 und 25 Zeichen lang ist. Das ist Käse. Sorge lieber dafür, dass die DB nur Passwörter enthalten kann, die diesen Kriterien entsprechen.

Du und Amica widersprecht euch jetzt in der Aussage, ob das sicher ist.

Der mit dem gezeigten Code dargestellte Ansatz ist sicher. Will sagen: Die Idee ist richtig. Die Umsetzung allerdings noch mangelhaft.
Ob du HTTPS nutzt oder nicht, ist nicht ersichtlich. Solltest es aber nutzen, sagt Amica. Du kennst doch den Spruch vom schwächsten Glied der Kette ...?

[AmicaNoctis]

Wie kommst du im "PHP als CGI Modus" an den Usernamen?

PHP als CGI ist zwar keine Option für mich, aber stehen nicht alle Request-Headers in diesem Fall dann im $_ENV-Array?

[combie]

Mein Kenntnisstand und meine (erfolglosen) Versuche entsprechen dem Handbuch.

The HTTP Authentication hooks in PHP are only available when it is running as an Apache module and is hence not available in the CGI version.

Und unterschlägt die Header.

PHP als CGI ist zwar keine Option für mich,

Eine Insel ?
Viele Massenhoster nutzen dieses.
z.B. Strato und 1&1
Auch "meine" Server.

Man bekommt die User/Domains sonst nicht vernünftig isoliert

[fireweasel]

Login-Formulare haben (das ist meine Privatmeinung) absolut keinen praktischen Sinn und dienen nur dazu, das Login schicker zu machen, als den Standard-Authentifizierungsdialog des jeweiligen Browsers. Sicherer sind sie jedenfalls nie.

Sie haben den Vorteil, dass ein explizites Ausloggen möglich ist, und die Lebensdauer einer Logon-Session begrenzt werden kann. Mit der HTTP-Authentifizierung ist sowas AFAIK nicht möglich[1]. Für Client-Computer, die von mehreren Personen genutzt werden, fällt dieses Verfahren damit aus. (Man korrigiere mich, wenn ich Unsinn erzähle.)

... und dann war da noch das Phishing-Risiko über den <img>-Trick.

[1] Jeder Browser hat seine eigene "Auslog"-Variante und der Benutzer muss zu jedem Zeitpunkt den richtigen Button im Dialogfenster erwischen.

[combie]

Einen Status 401 senden, dann sollten die Browser einen Schock bekommen und Authentifizierungsdaten vergessen.

[fireweasel]

Einen Status 401 senden, dann sollten die Browser einen Schock bekommen und Authentifizierungsdaten vergessen.

Hast du das schon mal erfolgreich versucht?
Wenn ja, wie hast du herausbekommen, ob der Browser auch tatsächlich die "Authentifizierungsdaten vergessen" hat?

[combie]

Da im meinem Umfeld kein PHP Modul läuft, kann ich das jetzt nicht testen. Aber ich bin mir recht sicher.

Wenn ja, wie hast du herausbekommen, ob der Browser auch tatsächlich die "Authentifizierungsdaten vergessen" hat?

Die fehlenden Einträge in $_SERVER

[AmicaNoctis]

Kann ich bestätigen. Ich benutze in einem Projekt seit längerem nur Digest Auth (inkl. Logoff) und das funktionierte in bisher jedem Browser so (PHPMyAdmin macht es übrigens ebenso, auch wenn es da zu der unschönen Passwort-Eingabeaufforderung kommt, die man dann abbrechen muss).