Hi hi,

ich bastel gerade etwas an meine Hompeage rum und bin gerade beim Login.

Wenn ich mich registriere gebe ich ein Passwort an und verschlüssle diese mit md5 und leg es in die Datenbank. Wenn ich mich nun einloggen will dann geb ich mein PW ein und dann muss ich das mit dem md5 hashwert in der DB vergleichen. Nur wie mach ich das?

Du holst dir mit nem SELECT das verschlüsselte Paßwort zu deinem User von der Datenbank und vergleichst es mit dem md5-Produkt dessen, was dein User als Passwort übergeben hat.

So etwa:

$result = mysql_query("SELECT password FROM user WHERE uid = '$id'",$db);

$row = mysql_fetch_row($result);


if ($row !== NULL)

{

  if ($row[0] == md5($_POST["password_feld"])

    //dann biste eingeloggt

  else

    //sonst halt net 

}

[/PHP]

Wo ist dat Problem?

Du kannst nur die Hashwerte vergleichen wie in kLeiner_HobBes Beispiel zu sehen ist. Eine andere Möglichkeit gibt es nicht.

Frank

aberist es nicht so, das wenn ich ein und dasselbe wort mit md5 verschlüssel, beidemale unterschiedliche Hashwerte rauskommen?

Wenn ich "test" eingebe bekomm ich einmal als hash "abc" und des nächstemal "xyz" (als beispiel )

Somit sind die doch immer unterschiedlich.

nein, dem ist nicht so. Der Hash-Algorithmus ist zwar eine One-Way-Verschlüsselung, was aber nicht heißt, das aus einunddemselben Wort einmal dieser Code und ein andermal ein anderer Code rauskommt. Wenn es denn so wäre, dann wäre md5 meiner Meinung nach völlig sinnlos, da man es ja auch nicht mehr decodieren kann!

hmm.... dann isses ja gar einfach.

hab halt mal n bisserl rumgelesen wegen md5 und da hies es dann das man niemals in einem(!) leben den gleichen hashwert für ein Wort bekommen könnte

hmm.... dann isses ja gar einfach.

hab halt mal n bisserl rumgelesen wegen md5 und da hies es dann das man niemals in einem(!) leben den gleichen hashwert für ein Wort bekommen könnte

das ist nicht korrekt.

ein wort md5 verscchlüsselt, gibt immer die gleichen hash-Werte

Hmm .. ich hab immer gelesen, daß mit 99,99% Sicherheit zwei unterschiedliche Worte niemals denselben Hash-Wert ergeben. Also andersrum. Und überleg doch mal, wenn ein Wort unterschiedliche Hashwerte erzeugt, was für einen Sinn hätte die Verschlüsselung dann???

aber dann ist das doch recht unsicher

ich könnte doch jetzt mir n script basteln welches wörter (groß-,kleinbuchstaben, zahlen) von 4 zeichen bis 15 zeichen bastelt und diese mit md5 verschlüsselt, ab in ne datenbank mit den beiden werten und wenn ich mir dann die hashes von meinen usern hol und den dazu passenden wert in der datenbank suche hab ich das kennwort klartext...

aber ok, da bracuht man schon ne sehr schnelle datenbank um es in einem leben zu schaffen...

26 (buchstaben) * 2(gros/klein) + 10(zahlen) = 62 (mögliche zeichen)

768.909.704.948.766.668.552.634.368 mögliche kombinationen

Vorsicht:

Hashes sind _keine_ Verschlüsselung von etwas, sondern nur eine kryptographische Prüfsumme, d.h. im Krypto-Sprachgebrauch: der Part von "Integrität der Daten".

Will man Daten verschlüsseln nimmt man andere Algorithmen.

Und gegen BruteForce ist sowieso jede Verschlüsselung oder Hash nutzloch. Es kommt nur auf die Zeit an

taschentoast

aber ok, da bracuht man schon ne sehr schnelle datenbank um es in einem leben zu schaffen...

Genauso kannst du auch alle anderen Methoden, ein Passwort zu verschlüsen "bruteforcen", es ist alles nur eine Frage der Zeit.

als Code würde ich es so machen:

 $result = mysql_query("SELECT uID FROM user WHERE 

loginname = '$logname' and passwd = md5('$pw')",$db);

$row = mysql_fetch_row($result);


if ($row !== NULL)

{

  // Willkommen drin...

} 

[/PHP]

Auch wenn der Unterschied nicht groß ist zu Hobbes Vorschlag, ich finde die Lösung eleganter. Auch bleibt das (original) PW des Benutzers so in der DB und wird direkt da verglichen und nicht ausgelesen und weitergegeben. Klar ist das jetzt keine Möglichkeit das Ding irgendwie abzufangen oder so... aber warum nicht die MySQL-Fähigkeit zum Hasherzeugen nutzen?

Ich bin der Ansicht, das ist besser so...

Hast schon recht, es ist keine Verschlüsselung. Man kann es in dem Sinne auch nicht rückentschlüsseln, sondern nur per BruteForce per Dictionary oder allen Kombinationen jeweils Hashwerte erzeugen und die vergleichen, wenn's hinhaut, hat man das Paßwort "geknackt". Das wäre ja nahezu die gleiche Vorgehensweise, wie Snowman es vorschlägt, aber bei 7,68e+26 Kombinationsmöglichkeiten ist der Zeitaufwand, den man zum Knacken braucht sehr wahrscheinlich länger als die Lebensdauer des Paßwortes

Hast schon recht, es ist keine Verschlüsselung. Man kann es in dem Sinne auch nicht rückentschlüsseln, sondern nur per BruteForce per Dictionary oder allen Kombinationen jeweils Hashwerte erzeugen und die vergleichen, wenn's hinhaut, hat man das Paßwort "geknackt". Das wäre ja nahezu die gleiche Vorgehensweise, wie Snowman es vorschlägt, aber bei 7,68e+26 Kombinationsmöglichkeiten ist der Zeitaufwand, den man zum Knacken braucht sehr wahrscheinlich länger als die Lebensdauer des Paßwortes

und um das ganze noch weiter herauszuzögern, sollte man eine maximale Anzahl an Eingabe-Versuchen vorgeben und wenn diese überschritten ist eine Fehlermeldung ausgeben, damits dann nicht ganz so leicht ist,...

eine andere möglichkeit ist auch einen User-Account bei mehrfacher Falsch-Eingabe für z.b. 24h zu sperren....

Ich seh ehrlich gesagt den Gewinn nicht ganz in JesterDays Lösung. In der von mir beschriebenen Lösung wird das Paßwort gehasht in die Datenbank eingetragen, das heißt, selbst wenn jemand unberechtigtes in die DB schaut, sieht er nur die Hashs und müßte sie per BruteForce hacken.

Und das unverschlüsselte Paßwort wird so und so durch das PHP-Script laufen, da es idR über $_POST übergeben wird (Wer GET nimmt, ist selbst schuld *gg).

Ich seh ehrlich gesagt den Gewinn nicht ganz in JesterDays Lösung. In der von mir beschriebenen Lösung wird das Paßwort gehasht in die Datenbank eingetragen, das heißt, selbst wenn jemand unberechtigtes in die DB schaut, sieht er nur die Hashs und müßte sie per BruteForce hacken.

Ich sagte nicht, das deine Lösung unsicherer ist. Aber allein schon brauchst du eine SQL-Abfrage mehr, du brauchst in deiner Lösung nämlich die uID zum User, der sich einloggen will. Und auch wenn du es nicht über die User ID machst, brauchst du ein paar PHP Schritte mehr. Klar sind das Millisekunden, aber auch Kleinvieh macht Mist Und wenn man es vermeiden kann...

EDIT:

Ausserdem spart es einige Zeilen Code und macht ihn dadurch übersichtlicher.

ausserdem wird der webserver entlastet und die Datenbank, die auf den meisten Seiten sowieso nicht start ausgelastet ist wird ein wenig mehr arbeit "aufgehalst"

man sollte generell funktionen der Datenbank nutzen, da man ja sonst das ganze zeug selbst nochma machen muss

Und das unverschlüsselte Paßwort wird so und so durch das PHP-Script laufen, da es idR über $_POST übergeben wird (Wer GET nimmt, ist selbst schuld *gg).

Der Unterschied zw. POST und GET macht, wenn du das PW abfangen kannst, auch keinen Unterschied mehr. Klar, GET siehst du in der URL, aber du wirst ja wissen, was du gerade eingegeben hast Wenn du den Verkehr zw. Client und Webserver "mitlesen" kannst, ist POST auch nicht sicherer. Es sei denn, du benutzt SSL, dann sieht es natürlich anders aus. Dann wird POST nämlich verschlüsselt gesendet, GET aber nicht.

EDIT:

Das ist nur als kleines "Besserwisser-Syndrom" zu verstehen POST ist immer GET vorzuziehen IMHO.

Natürlich ist POST vorzuziehen. Ich meinte aber vor allem, daß es manche User gibt, die auf ne Login-Seite gehen, die nicht redirected wird und das PW noch im GET-Aufruf drinsteht. Und diese Adresszeile wird dann in irgendnem Forum oder so gepostet. Da freut sich jeder *gg

Natürlich ist POST vorzuziehen. Ich meinte aber vor allem, daß es manche User gibt, die auf ne Login-Seite gehen, die nicht redirected wird und das PW noch im GET-Aufruf drinsteht. Und diese Adresszeile wird dann in irgendnem Forum oder so gepostet. Da freut sich jeder *gg

Ok, das stimmt auch wieder