Hi Christian,
Am besten speichert man nur das in der Session, was sich nicht umgehen lässt. Z.B. die ID des Users, der sich eingeloggt hat. Nicht aber das User-Objekt aus der Datenbank.
Aber für einen Angreifer wäre es doch einfacher, irgendeine UserID zu erraten. Mit dem gehashten Passwort dahinter wird es etwas schwieriger.
Ich frage mich gerade, warum ich gehashte Passwörter nicht in einem Cookie speichern soll. Also ich verstehe es Praktisch nicht. Würde etwas weiterhin dagegen sprechen, wenn ich password_hash() nutze? Dann sind die Daten ja noch mehr verunstaltet. password_hash() werde ich auf jedenfall schon mal implementieren.
Das bedeutet, dass die Passwort-Informationen im Cookie des Users auf dessen Computer abgelegt werden. Urgh, ja, das will man definitiv nicht.
Auch nicht, wenn die Daten gehashed und verunstaltet sind?
secure
, wie oben schon erwähnt, undhttponly
sollten in jedem Fall gesetzt werden.
Ja, httponly hatte ich auch noch nicht ganz verstanden.
nach der Authentifizierung wird eine neue Session-ID generiert, so dass der Angreifer nicht mehr die alte Session-ID nutzen kann.
Wie mach ich das? Wenn ich den Sessionwert im Cookie nach dem Login ändere, passiert irgendwie nichts. Ich werde nicht mal ausgeloggt. Wonach richtet sich die Session? Ich dachte, der Wert im Cookie für die Session ist das wichtige zur erkennung des Users, aber selbst wenn ich diesen Wert ändere, ist die Session noch Aktiv. Ist die Session an die IP des Users gebunden?
Bis bald
Hosen sind Blau