Hi Logik,
Beim abschicken: Javascript: Erstelle md5 Hashsumme rufe Dokument auf welches die Klasse "Loginsystem" aufruft
Was erhoffst du dir davon? Höhere Sicherheit? Die hast du damit definitiv nicht, das ist genauso sicher, als wie wenn das Passwort im Klartext übertragen würde.
Wenn ich als Angreifer die Verbindung abhöre, dann kriege ich nur die md5-Summe des Passwortes zu lesen und nicht das Passwort im Klartext - aber das reicht mir vollkommen! Um mich als Angreifer unter einem fremden Benutzerkonto anzumelden, brauche ich ja ebenfalls nur die md5-Summe des Passwortes an den Server zu schicken, also genau das, was ich beim Abhören mitgelesen habe.
class Loginsystem{
function Login(Name, PW){
// Nehme Name und PW entgegen
// erstelle sha1 Hashsumme
eine sha1-Summe von der md5-Summe? Wozu? Das verkompliziert dein Verfahren lediglich, ohne einen deutlichen Mehrgewinn an Sicherheit zu bringen. Abgesehen davon ist SHA-1 nicht mehr als wirklich sicher zu betrachten, vielleicht solltest du also lieber ein SHA-256 oder etwas ganz anderes vorziehen.
// Guck in Datenbank nach ob beides vorhanden ist
// Lese Userid aus
// Hashwert der Userid (sha1) = HU
// Erstelle Session und schreibe dort HU rein
Wozu willst du den Hashwert der Userid in der Session? Das ist doch äußerst unbequem - da kannst du die Userdaten nicht anhand der Userid aus der Datenbank auslesen, dazu müsstest du erst auf alle Userids der Datenbank die Hashfunktion anwenden um den entsprechenden Datensatz zu finden.
Fortlaufende Zahlen haben die hervorragende Eigenschaft, dass sie eindeutig sind. Die Hashwerte zu zwei von diesen Zahlen können identisch sein - das ist zwar unwahrscheinlich, aber möglich. Warum also dieses Risiko eingehen?
// Erstelle Cookie und schreibe dort HU rein
Wozu denn das noch? Der User wird anhand der Session wiedererkannt. Und die Session wird anhand des Session-Cookies erkannt. Wozu willst du also noch ein Cookie mit dem Usernamen?
Und warum schreibst du hier nur den Hash des Usernamens rein? Erhoffst du dir hier mehr Sicherheit? Auch hier muss ich sagen: Nein. Sofern du dieses Cookie benutzt um durch eine Zugangskontrolle zu kommen, so brauche ich als Angreifer lediglich die Verbindung abzuhören und schon habe ich den Hashwert, ich weiß nicht wieder User heißt, aber das muss ich auch nicht wissen, wenn der Hashwert des Usernamens bereits vollkommen ausreicht um durch die Zugangskontrolle zu kommen.
// Schreibe in die Datenbank aktuelles Datum und Uhrzeit rein + HU
Du hast die Userid aus der Datenbank ausgelesen und willst du die gehashte Userid wieder in die Datenbank reinschreiben - Wozu?
function auth(Cookie, Session){
// vergleiche HU von Cookie und Session
// Falls es nicht stimmt, abbrechen#
Ok, nun verstehe ich warum du mit zwei Cookies arbeiten willst - damit zu zwei Mechanismen hast um zu prüfen ob der User eingeloggt ist.
Aber warum? Das bringt nichts, wenn ich einmal eine Verbindung abgehört habe, dann habe ich sofort das HU-Cookie, als auch das Session-Cookie, da bei jedem Request vom Browser beide Cookies übermittelt werden müssen. Ergo kannst du problemlos auf ein Cookie kürzen.
Was du eigentlich willst, ist SSL zu benutzen, also deine Seiten über https aufzurufen. Alles andere ist nur Trickserei, die den Angreifer vielleicht etwas mehr Zeit kostet, dein System aber nicht sicherer macht, als es ohnehin wäre.
Vielleicht könntest du nur den eigentlichen Login-Prozess, also das Übermitteln von Benutzername und Passwort über eine SSL-verschlüsselte Verbindung laufen lassen und alle anderen Seiten über normales, unverschlüsseltes HTTP. Dann könnte man zumindest schon mal die Benutzerdaten nicht abhören.
Und um Session-Diebstahl zu verhindern beschränkst du dann noch die Lebensdauer einer Session auf 20 Minuten o.ä. bzw. beendest die Session automatisch nach 5 Minuten Inaktivität. Interessant kann auch die Idee sein, bei jedem Aufruf eine neue Session-ID zu generieren (session_regenerate_id()), wird dies sauber implementiert, so ist ein Session-Diebstahl bereits sehr schwer und nur so lange möglich, wie der eigentliche User noch keinen weiteren Request nach dem erfolgreich abgehörten Request vorgenommen hat.
Viele Grüße,
~ Dennis.