Passwortabfrage funktioniert nicht

[Tobi]

Guten Tag,

Ich habe ein Administrationspanel von einer Homepage in PHP geschrieben, was auch funktioniert aber es fehlt noch der Passwortschutz. Ich habe versucht das ganze wieder ganz normal mit isset Abfrage zu erledingen, aber das Panel wird auch nach Eingabe nicht angezeigt. Was könnte ich falsch gemacht haben?

if(isset($_POST['Login']))  
{  
   if(isset($_POST['username']))  
   {  
      if(isset($_POST['passwort']))  
      {  
         $password = $_POST['passwort'];  
         $truepw = 'Meinpasswort';  
         if($password = $truepw)  
         {  
            echo "  
            <form method='POST' action='administrationstartseite.php'>  
            <p><textarea cols='70' rows='20' name='text' wrap='hard'>$wert</textarea></p>  
            <p><input type='submit' value='Editieren' name='absenden'><input type='submit' value='anfangswerterstellen'   		   name='create'></p>  
            </form>  
            ";  
            }  
            else  
            {  
               echo "Falscher Benutzer/Passwort";  
            }  
         }  
      }  
   }  
}

[dedlfix]

Tach!

$password = $_POST['passwort'];

Warum kopierst du den Wert nochmal und verwendest ihn nicht direkt?

$truepw = 'Meinpasswort';

Auch das Passwort musst du nicht unbedingt in eine Variable stecken, wenn du den Wert gleich anschließend und nur ein einziges Mal verwendest.

if($password = $truepw)

Vergleich und Zuweisung verwenden unterschiedliche Operatoren. Weil du hier eine Zuweisung notiert hast, die aufgrund der Zuweisung eines nichtleeren Strings immer true ergibt, ist die Bedingung stets erfüllt.

dedlfix.

[Bobby]

Moin

Guten Tag,

Ich habe ein Administrationspanel von einer Homepage in PHP geschrieben, was auch funktioniert aber es fehlt noch der Passwortschutz. Ich habe versucht das ganze wieder ganz normal mit isset Abfrage zu erledingen, aber das Panel wird auch nach Eingabe nicht angezeigt. Was könnte ich falsch gemacht haben?

if(isset($_POST['Login']))

{
   if(isset($_POST['username']))
   {
      if(isset($_POST['passwort']))
      {
         $password = $_POST['passwort'];
         $truepw = 'Meinpasswort';
         if($password = $truepw)
         {
            echo "
            <form method='POST' action='administrationstartseite.php'>
            <p><textarea cols='70' rows='20' name='text' wrap='hard'>$wert</textarea></p>
            <p><input type='submit' value='Editieren' name='absenden'><input type='submit' value='anfangswerterstellen'       name='create'></p>
            </form>
            ";
            }
            else
            {
               echo "Falscher Benutzer/Passwort";
            }
         }
      }
   }
}

  
Boar, was für spaghetticode... Die Prüfung kannst du komplett in eine Abfrage tun und den richtigen vergleichsoperator (==) statt der Zuweisung (=) verwenden... Außerdem solltest du dein pw sichern z.b. Mit MD5 und Salt. Niemals klar abspeichern... es kann ka mal sein, dass das php-script nicht durch den interpreter gejagt wird sondern plain beim client ankommt. da wäre dein pw zu lesen, wenn es plain drinsteht.  
  
Es könnte so aussehen:  
  
~~~php
  
$savedpassword=..... ; // hier der MD5 String aus Passwort mit Salt angefügt (Salt-32bit)  
If(isset($_POST['Login']) && isset($_POST['username']) && isset($_POST['password']) && md5($_POST['password'].'salt-32bit')==$savedpassword)  
{  
  // hier Ausgabe wenn alles ok  
}  
Else  
{  
  // hier das wenn's nicht stimmt  
}  

Gruß Bobby

[dedlfix]

Tach!

Außerdem solltest du dein pw sichern z.b. Mit MD5 und Salt.

Ich denke, das Salt bringt in diesem Fall keinen gesteigerten Wert. Zum einen handelt es sich um lediglich ein einzelnes Passwort. Bei vielen zu speichernden Passwörtern will man durch unterschiedliche Salt-Werte verhindern, dass zwei Passwörter denselben Hash-Wert erzeugen und man so Rückschlüsse von einem auf andere ziehen kann. Zum anderen kann ein schwaches Passwort bei bekanntem Salt genauso leicht per Brute-Force geknackt werden wie eins ohne Salt. Auch bei einem starken Passwort erhöht ein bekanntes Salt den Aufwand des Knackens nicht weiter.

Wenn dem Angreifer der Hashwert nicht bekannt ist, kann er nur Passwort-Versuche auf das Script absetzen. Dabei kommt es nur noch auf die Stärke des Passworts an und wie einfach/schnell er die Versuche starten kann.

dedlfix.

[Bobby]

Moin

Ich denke, das Salt bringt in diesem Fall keinen gesteigerten Wert. Zum einen handelt es sich um lediglich ein einzelnes Passwort. Bei vielen zu speichernden Passwörtern will man durch unterschiedliche Salt-Werte verhindern, dass zwei Passwörter denselben Hash-Wert erzeugen und man so Rückschlüsse von einem auf andere ziehen kann. Zum anderen kann ein schwaches Passwort bei bekanntem Salt genauso leicht per Brute-Force geknackt werden wie eins ohne Salt. Auch bei einem starken Passwort erhöht ein bekanntes Salt den Aufwand des Knackens nicht weiter.

Wenn dem Angreifer der Hashwert nicht bekannt ist, kann er nur Passwort-Versuche auf das Script absetzen. Dabei kommt es nur noch auf die Stärke des Passworts an und wie einfach/schnell er die Versuche starten kann.

Der hashwert wird ja aber sichtbar gespeichert. (Sichtbar wenn plain übertragen)

Deshalb schrieb ich 32 Bit Salt... Und er bringt definitiv etwas... Es gibt viele DBs im Netz, wo man MD5 Springs eingeben kann umschwenken gespeichert, das klar-PW zurück bekommt. Und da sind ebenso bereits viele starke PWs gespeichert. Mit einem 32-Bit- Salt ist da die Erfolgschance nahe 0... Deshalb ist das durchaus sinnvoll und kann nicht Schaden...

Gruß Bobby

[Bobby]

Moin,

Blödes iPhone und seine automatische Ersetzung. "Umschwenken gespeichert" is Quatsch. ;)

Gruß Bobby

[dedlfix]

Tach!

Ich denke, das Salt bringt in diesem Fall keinen gesteigerten Wert. Zum einen handelt es sich um lediglich ein einzelnes Passwort. Bei vielen zu speichernden Passwörtern will man durch unterschiedliche Salt-Werte verhindern, dass zwei Passwörter denselben Hash-Wert erzeugen und man so Rückschlüsse von einem auf andere ziehen kann. Zum anderen kann ein schwaches Passwort bei bekanntem Salt genauso leicht per Brute-Force geknackt werden wie eins ohne Salt. Auch bei einem starken Passwort erhöht ein bekanntes Salt den Aufwand des Knackens nicht weiter.

Wenn dem Angreifer der Hashwert nicht bekannt ist, kann er nur Passwort-Versuche auf das Script absetzen. Dabei kommt es nur noch auf die Stärke des Passworts an und wie einfach/schnell er die Versuche starten kann.

Der hashwert wird ja aber sichtbar gespeichert. (Sichtbar wenn plain übertragen)

Den Fall hab ich im oberen Abschnitt betrachtet. Aber Sicherheit muss auch garantiert werden, wenn du an Hash-Wert und Salt nicht herankommst. In dem Fall reicht ein unsicheres Passwort und ein Webserver, der beim Brute-Force mitspielt.

Deshalb schrieb ich 32 Bit Salt... Und er bringt definitiv etwas... Es gibt viele DBs im Netz, wo man MD5 Springs eingeben kann umschwenken gespeichert, das klar-PW zurück bekommt. Und da sind ebenso bereits viele starke PWs gespeichert. Mit einem 32-Bit- Salt ist da die Erfolgschance nahe 0... Deshalb ist das durchaus sinnvoll und kann nicht Schaden...

Rainbow-Tables. Ich muss zugeben, dass ich nicht auf dem aktuellen Stand bin, welche Sorten Rainbow-Tables mittlerweile verfügbar sind. Wenn ich mal Free Rainbow Tables als Referenz annehme, dann sehe ich da bei MD5 maximal 8 Stellen bei mixalpha-numeric-space. Die anderen sind teilweise länger, verwenden aber auch weniger Zeichen. Das heißt für mich, dass diese Tabellen immer noch nutzlos sind, wenn das Passwort selbst ausreichend komplex ist.

Mir fallen drei Situationen ein:

• Das Passwort ist sehr schwach, dann kommt es zusammen mit den 4 Zeichen bei 32-bit-Salt möglicherweise noch in den von Rainbow-Tables abgedeckten Bereich. Nix gewonnen.
• Das Passwort ist komplex und selbst nicht mehr in den Tabellen enthalten, dann bringt das Salt vielleicht was für die Zukunft, wenn ich mein Passwort nicht der dann üblichen Rechenleistung anpasse, um Brute-Force zu erschweren.
• Das Passwort kommt zusammen mit dem Salt nicht in den Rainbow-Tables vor. Ein Salt bringt nur dann beim Brute-Force Punkte, wenn sich damit die Rechenzeit signifikant verlängert - die Rechenzeit für die Ermittlung eines Hash-Wertes. Wenn ich den MD5-Algorithmus richtig verstehe, ist 512 Bit (=64 Byte) das Schlüsselwort. Alles bis zu dieser Länge benötigt dieselbe Rechenzeit. Wenn das richtig ist, bringt das Salt also erst dann einen Nachteil für Brute-Force, wenn damit die 512er Grenze überschritten wird.

Lange Rede kurzer Sinn: Einfach nur Salt hinzufügen bringt dich nicht zwangsläufig auf die sichere Seite.

dedlfix.

[Tom]

Hello,

Boar, was für spaghetticode...

Ich kann kein einziges "Goto" oder ähnliches entdecken, sondern sehe - ganz im Gegenteil - nur einen Ausschnitt aus einer sauber strukturierten Programmierung
http://de.wikipedia.org/wiki/Strukturierte_Programmierung

Und der Coding-Style ist auch nachvollziehbar und verständlich.

Spaghetti-Code geht anders!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Bobby]

Moin,

Spaghetti-Code geht anders!

Dann Nenn es schlangencode... Solche tiefen if-Verzweigungen sind einfach nicht schön, wenn man keine Alternativen setzt.

Gruß Bobby

[Tom]

Hello,

Dann Nenn es schlangencode... Solche tiefen if-Verzweigungen sind einfach nicht schön, wenn man keine Alternativen setzt.

Wenn man keine Alternativen angibt, sind es keine Verzweigungen, sondern nur einfache Bedingungen. Sicherlich ist es meistens angebracht, im Else-Zweig eine Fehlerbehandlung vorzusehen, aber das ist nicht zwingend immer der Fall.

Liebe Grüße aus Bad Driburg

Tom vom Berg

[Der Martin]

Hallo,

Wenn man keine Alternativen angibt, sind es keine Verzweigungen, sondern nur einfache Bedingungen. Sicherlich ist es meistens angebracht, im Else-Zweig eine Fehlerbehandlung vorzusehen, aber das ist nicht zwingend immer der Fall.

das ist auch hier nicht der Punkt, glaube ich. Was mir beim Ansehen des Codes missfällt, ist vor allem die Verschachtelung von drei if-Abfragen (genaugenommen nur zwei, aber der else-Zweig der dritten ist auch nicht der Brüller), die de facto eine UND-Verknüpfung der Bedingungen ergeben. Also warum nicht gleich die drei Bedingungen in *einer* if-Abfrage formulieren? Dann erkennt man nämlich leichter, was da eigentlich gemeint ist.

Dazu kommt speziell im Fall PHP, dass man mehrere Variablen in einem Aufruf von isset() abfragen kann, was auch der Übersichtlichkeit zugute kommt:

if (isset($_POST['Login'], $_POST['username'], $_POST['passwort']))

Die Verwechslung von Vergleich und Zuweisung wurde ja schon angesprochen, ebenso das überflüssige Umkopieren.
Die Verwendung eines p-Elements als Container für Formularelemente halte ich übrigens für semantisch fragwürdig; an der Stelle würde ich eher fieldset empfehlen.

So long,
 Martin

[Jens Holzkämper]

Tach,

Außerdem solltest du dein pw sichern z.b. Mit MD5 und Salt.

nicht md5, Passworte hashen bitte (auch wenn das hier nicht viel bringt), aber dann bitte mit einer dafür vorgesehenen (langsamen) Hashfunktion wie z.B. scrypt

mfg
Woodfighter

[Bobby]

Moin

nicht md5, Passworte hashen bitte (auch wenn das hier nicht viel bringt), aber dann bitte mit einer dafür vorgesehenen (langsamen) Hashfunktion wie z.B. scrypt

Warum nicht md5? Ich lerne gern dazu... Bisher erschien mir das mit dem entsprechend langen Salt als ziemlich sicher. Die Kollisionswahrscheinlichkeit ist auch relativ gering. Also, was spricht gegen md5?

Gruß Bobby

[Jens Holzkämper]

Tach,

Warum nicht md5? Ich lerne gern dazu... Bisher erschien mir das mit dem entsprechend langen Salt als ziemlich sicher. Die Kollisionswahrscheinlichkeit ist auch relativ gering. Also, was spricht gegen md5?

md5 und andere kryptographische Hashes (SHA, etc.) werden ausgewählt, weil sie schnell sind; das führt dazu, dass man ein paar Milliarden Hashes pro Sekunde pro Grafikkarte berechnen kann (Artikel von 2008: http://www.geeks3d.com/20081123/geeks3d-test-cracking-md5-passwords-with-a-geforce-graphics-card/, mit heutiger Hardware entsprechend schneller). Heutzutage mietet man sich dazu einfach ein paar GPUs in der Cloud…

mfg
Woodfighter