Sha1 password Problem auf Mac
Andreas E.
- php
Guten Abend allerseits,
auf meiner Homepage benutze ich ein eigens angefertigtes Login script.
Dazu speichere ich die Passwörter mit sha1 in ein Char(40) latin1_swedish_ci ab. Bei der Eingabe des Passworts wird dieses per sha1 "verhasht" und mit dem aus der Datenbank verglichen.
Nun habe ich allerdings festgestellt, dass einige User sich nicht einloggen können, obwohl sie das richtige Passwort eingeben.
Merkwürdigerweise scheint dies recht plötzlich zu passieren, ohne dass sie irgendwas verändert hätten.
Ich habe dieses lokal bei mir (Windows 7) ausprobiert und keine Loginprobleme festgestellt. Da alle diese User Mac benutzten, vermute ich, dass dieses dahinter steckt. Zudem habe ich einen weiteren gemeinsammen Nenner gefunden:
alle Passwörter enden auf 6.
Ich weiß nicht, woran dies liegen könnte, da es bei mir eben mit allen Passwörtern funktioniert.
Weiß einer von irgendeinem Fehler dieser Art oder wie man dies behenben/umgehen kann?
Hier mein entsprechender Code:
$shapass = sha1($_POST['password']);
$username = mysql_real_escape_string($_POST['username']);
$sql = ("SELECT userid,username FROM users
WHERE
username = '".$username."' AND
password = '".$shapass."'");
$result = mysql_query($sql) or die (mysql_error());
$num = mysql_num_rows($result);
if ($num == 1) {
$list = mysql_fetch_object($result);
// SESSION SETZEN ...
$_SESSION['userid'] = $list->userid;
}
Hallo,
Nun habe ich allerdings festgestellt, dass einige User sich nicht einloggen können, obwohl sie das richtige Passwort eingeben.
was steht in der HTTP-Logdatei vom Server? Was wurde auf Netzwerkebene übertragen (tcpdump)? Gibts eventuell auch ein Log vom PHP-Interpreter?
Hier mein entsprechender Code:
$shapass = sha1($_POST['password']);
Du verwendest hoffentlich HTTPS? Außerdem solltest du das Hashing auf dem Clientcomputer zu vollziehen.
$username = mysql_real_escape_string($_POST['username']);
$sql = ("SELECT userid,username FROM users
WHERE
username = '".$username."' AND
password = '".$shapass."'");
Hier könntest du [prepared statements](http://php.net/manual/de/pdo.prepared-statements.php) benutzen.
> $result = mysql\_query($sql) or die (mysql\_error());
Mach ich auch immer so ( ;-) ) aber wir haben ja gelernt: [die() ist ebenso sehr eine Fehlerbehandlung, wie Suizid eine Heilmethode ist.](http://community.de.selfhtml.org/zitatesammlung/zitat1282)
Grüße
Hallo,
Nun habe ich allerdings festgestellt, dass einige User sich nicht einloggen können, obwohl sie das richtige Passwort eingeben.
was steht in der HTTP-Logdatei vom Server? Was wurde auf Netzwerkebene übertragen (tcpdump)? Gibts eventuell auch ein Log vom PHP-Interpreter?
Ich wüsste leider nicht, wie ich tcpdump überprüfen sollte, da ich ja nur einen Webspace, nicht aber einen eigenen Server besitze.
Komischerweise endet der Errorlog im März. Vielleicht war die Datei bereits zu groß.
Hier mein entsprechender Code:
$shapass = sha1($_POST['password']);
Du verwendest hoffentlich HTTPS? Außerdem solltest du das Hashing auf dem Clientcomputer zu vollziehen.
Da ich dies einmal von einem gegebenen Loginscript übernommen habe und auch nirgends bisher anders gesehen habe, frage ich mich gerade, wie ich das denn auf dem Clientcomputer machen kann, da doch die php Dateien trotzdem auf Seite des Servers liegen.
$username = mysql_real_escape_string($_POST['username']);
$sql = ("SELECT userid,username FROM users
WHERE
username = '".$username."' AND
password = '".$shapass."'");
> Hier könntest du [prepared statements](http://php.net/manual/de/pdo.prepared-statements.php) benutzen.
Danke, werde ich mal berücksichtigen!
Hallo,
Ich wüsste leider nicht, wie ich tcpdump überprüfen sollte, da ich ja nur einen Webspace, nicht aber einen eigenen Server besitze.
Es wäre schon interessant zu "sehen" was der Client wirklich an den Server sendet. Dazu reicht ein funktionsfähiges tcpdump am Client.
Komischerweise endet der Errorlog im März. Vielleicht war die Datei bereits zu groß.
Tja - finde es raus. In der Datei können wichtige Informationen drin stehen.
Da ich dies einmal von einem gegebenen Loginscript übernommen habe und auch nirgends bisher anders gesehen habe, frage ich mich gerade, wie ich das denn auf dem Clientcomputer machen kann, da doch die php Dateien trotzdem auf Seite des Servers liegen.
Du solltest meiner Meinung nach das Hashen auf dem Clientcomputer vollziehen. Wie das mit z.B. JavaScript funktioniert verrät dir Google.
Grüße
Tag,
Komischerweise endet der Errorlog im März. Vielleicht war die Datei bereits zu groß.
Tja - finde es raus. In der Datei können wichtige Informationen drin stehen.
Im Errorlog steht nichts auffälliges, außer, dass eine Datei von TinyMCE nicht geladen werden konnte, was ich jetzt beseitigt habe.
Da ich dies einmal von einem gegebenen Loginscript übernommen habe und auch nirgends bisher anders gesehen habe, frage ich mich gerade, wie ich das denn auf dem Clientcomputer machen kann, da doch die php Dateien trotzdem auf Seite des Servers liegen.
Du solltest meiner Meinung nach das Hashen auf dem Clientcomputer vollziehen. Wie das mit z.B. JavaScript funktioniert verrät dir Google.
»»
Nur was ist, wenn Javascript deaktiviert ist? Wo liegt denn der Unterschied, ob man das Client oder Serverseitig erledigt?
Auf jeden Fall habe ich festgestellt, dass es zumindest nicht an Mac liegen kann, da das Problem nun auch bei einem Windows 7 User auftrat.
Vielleicht liegt dann vorher irgendwo der Fehler, der vielleicht eine der Variablen falsch setzt. Aber sehr komisch das ganze.
Hallo,
Nur was ist, wenn Javascript deaktiviert ist? Wo liegt denn der Unterschied, ob man das Client oder Serverseitig erledigt?
Nunja - man könnte den Benutzer zwingen es zu aktivieren; das ist aber eine andere Diskussion.
Der Unterschied liegt in einer Erhöhung der Sicherheit. Wenn du den Hash bereits auf dem Client bildest, läufst du nicht Gefahr, dass das Passwort eventuell im Plaintext über den Ether geschickt wird. Vorausgesetzt, du definierst den Client als vertrauenswürdig.
Auf jeden Fall habe ich festgestellt, dass es zumindest nicht an Mac liegen kann, da das Problem nun auch bei einem Windows 7 User auftrat.
Aha - vielleicht liegts am Browser? Am Cache? Am Netzwerk?
Vielleicht liegt dann vorher irgendwo der Fehler, der vielleicht eine der Variablen falsch setzt. Aber sehr komisch das ganze.
Das lässt sich relativ leicht mit print() herausfinden.
Grüße
Hey,
Auf jeden Fall habe ich festgestellt, dass es zumindest nicht an Mac liegen kann, da das Problem nun auch bei einem Windows 7 User auftrat.
Aha - vielleicht liegts am Browser? Am Cache? Am Netzwerk?
Ich habe mal den Nutzer dazu aufgefordert, Cookies und Cache zu löschen, mal schauen was passiert.
Vielleicht liegt dann vorher irgendwo der Fehler, der vielleicht eine der Variablen falsch setzt. Aber sehr komisch das ganze.
Das lässt sich relativ leicht mit print() herausfinden.
Ja, das habe ich überprüft, aber daran liegt es nicht.
Ich habe Folgendes ausprobiert. Der User hat mir sein Passwort gegeben und dann hat er sich versucht einzuloggen und es klappte nicht und ich erhielt aber den sha1 Hash.
Dann habe ich mich versucht einzuloggen und es klappte, allerdings war der Hash auch ein ganz anderer.
Erzeugt denn die sha1 Funktion andere Werte auf verschiedenen Computern?
Jetzt versuche ich das ganze direkt in MySQL zu machen, also mit
WHERE password = sha1('".$_POST['password']."')
und dann mal sehen, ob es besser funktioniert.
Auf der MySQL Seite steht unter Encryptern auch etwas von Blob und gewisse Leerzeichen die normale Stringtypen am Ende einfügen.
Mit Blob habe ich bisher nicht gearbeitet, könnte dies auch eine Ursache sein? Das würde mich allerdings dann doch verwundern, da sogar phpbb, Webspell und auch andere CMS VARCHAR oder CHAR als Datentyp benutzen.