nicht angemeldet
Deshalb würde ich gerne wissen, wenn es schlecht ist, was schlecht ist.
ich hab nicht gesagt, dass es schlecht ist - es ist sogar recht gut, wenn man sich sonst so ansieht, was hier herumfleucht - aber es gibt immer dinge die imho zu bemängeln sind:
return $db->error; ist keine fehlerbehandlung, ein normaler mensch sieht eine fehlermeldung die meistens das layout schrottet, das hilft ihm nicht weiter - hier gehört eine ordentliche geschichte hin, die dem normalen menschen erklärt, dass es grade nicht geht und dass bereits ein admin informiert ist
return 'Das eingegebene Password ist ungültig.';
das würd ich so auch nicht machen, früher oder später will man seine seite übersetzen, texte ändern oder sonstwas - strings oder einzelne wörter die änderbar sind oder übersetzt werden können, sollte man immer zentral auslagern
weiters ist die trennung der benutzername- und password-prüfung einerseits ressourcenlastiger (2 abfragen statt einer) und andererseits sicherheitskritisch, da man problemlos erst den benutzernamen bruteforcen kann (sofern dieser nicht bekannt ist und das ist bei vielen systemen der fall anzeigename != loginname, da es zum password zusätzlich noch einen zweiten string gibt, der geheimgehalten werden muss)
bruteforce-angriffe macht das wie erwähnt schon um einiges schwieriger
session mit der user id und dem hash des passwords zu setzen ist auch extrem schlau - zwar kann man damit noch nicht die daten rekonstruieren, aber man kann sich zumindest einloggen, wenn man die möglichkeit hat die cookie-informationen eines anderen auszuspähen da scheinbar nirgens hinterlegt wird, wie lange das login tatsächlich gültig ist
zudem ist mit bekanntwerden des algorithmus auch die sicherheit des hashes nicht mehr sichergestellt - die user id, und somit die ersten zeichen des klartext, sind bekannt - somit ist ein rainbow-angriff noch viel einfacher durchzuführen, da bei einem treffer sofort überprüft werden kann, ob es sich um das klartext-passwort handelt (zwar ist das extrem rechenintensiv, aber ein weiterer potentieller angriffspunkt)
ich würde ein INSERT ON DUPLICATE KEY UPDATE verwenden um einen eintrag in einer session-tabelle zu erzeugen, wenn benutzername und kennwort beim login-vorgang übereinstimmen mit einem beliebigen hash (zeit * zufallzahl * schuhgröße von kelly bundy) welcher dann als einzige information in einem cookie liegt - wenn die abfrage fehlschlägt, ist benutzername oder kennwort (oder beides) falsch, wenn die abfrage erfolgreich ist ist der benutzer eingeloggt - es fehlt dann lediglich eine weitere abfrage die die session-tabelle wieder bereinigt
alternativ lässt sich statt dem beliebigen hash natürlich auch die session-information von php dazu verwenden (das ist sogar schlauer), man speichert dann lediglich die session-id in der datenbank bzw in die session-tabelle
für verbesserungsvorschläge an meinen vorschlägen bin ich offen, ich lerne auch gerne dazu ;)