Um das mit der Session aus meiner Sicht nochmal zu verdeutlichen ... Ich hoffe ich schreibe nicht zu sehr am Thema vorbei ...
Es ist ratsam eindeutige Faktoren des Benutzers an einer Session zu binden - Beispiel: IP und Useragent. Dann ist es noch ratsam die Lebensdauer der Session einzuschränken. Des weiteren ist es ratsam, ein User bei jedem Login eine neue Session zu geben – alte hingegen löschen.
Szenario: (Verschlüsselung, Hard-TimeOut, Soft-TimeOut und XSS und Co. mal außen vor) …
Nach erfolgreichen Login:
Session_id wird vom System generiert und als Cookie gesetzt - oder per URL weiter gegeben.
Zusätzlich werden für die Wiedererkennung des Nutzers einige Daten in der DB gespeichert.
DB Beispiel:
session_id
session_user_id
session_user_ip
session_user_agent
session_user_time
Bei Aktionen wird nun immer verglichen ob die gespeicherten Daten, mit den übermittelten Daten, stimmen - Wenn nicht ist die Session ungültig.
Für mehr Sicherheit ist das Zusammenspiel entscheidend: - Verschlüsselte Übertragung
- Eingabevalidierung
- Session sollte nach einiger Zeit die Gültigkeit verlieren
- Session sollte eindeutiger an den User gebunden werden (IP und Useragent)
usw.
Zitat:
|
Das mit dem UserAgent lässt sich mir zu leicht umgehen. Daher auch die Überlegung aus IP und Agent eine Schlüssel zu generieren.
|
Dein Schlüssel ist für mich jetzt nix anderes als wenn Du den Useragent und die IP normal mit der Session_id in der DB speicherst. Eine Überlegung wäre vielleicht bei Jeder wichtigen Aktion nochmal noch einem extra Passwort zu fragen. Dieses sollte dann aber gesondert von den eigentlichen Benutzter Daten gespeichert werden.
Würde mich Interessieren wenn Du eine andere Lösung hast.
lg, -umbrella