Ein Loginscript
bearbeitet von Matthias ApselHallo Malcolm,
> > 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.
Das erraten bringt ihm aber doch nichts. Die Session verlässt den Server nicht, siehe auch mein voriges Posting.
> 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?
Du kannst doch nie wissen, ob der verwendete Hashing-Algorithmus nicht doch eine Lücke hat, die einem das erraten/errechnen des Passworts erlauben. Passwörter sind das Geheimnis, dass man benötigt, um Zugriff zu erhalten. Die schreibt man nicht an die Pinwand.
> > 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?
Mit [`session_regenerate_id](http://php.net/manual/de/function.session-regenerate-id.php) (natürlich mit `$delete_old_session` auf `true` gesetzt).
> Wonach richtet sich die Session? Ich dachte, der Wert im Cookie für die Session ist das wichtige zur erkennung des Users
Die Session-ID wird verwendet, um die Session wiederzuerkennen, richtig.
> aber selbst wenn ich diesen Wert ändere, ist die Session noch Aktiv. Ist die Session an die IP des Users gebunden?
Die oben erwähnte Funktion erzeugt eine neue Session-ID, so dass ein potentieller Angreifer nicht dieselbe Session-ID verwenden kann, mit der er den User zum Login-Form geschickt hat (Stichwort Session Fixation). Die alte Session-ID ist dann schlicht und ergreifend nicht länger mit der Session des Users verknüpft.
LG,
CK
--
<https://wwwtech.de/about>