molily: Wie gestalte ich ein sicheres Loginsystem? (Im Detail)

Beitrag lesen

Hallo,

Speziell in Hinsicht auf deinen Gedankengang halte ich Auth-* zu Cookies für gleichwertig. In beiden Fällen kann man das übertragene Datum serverseitig auswerten.

Es sind zwei unterschiedliche Ansätze und es ist m.M.n. verwirrend, sie ohne weiteres in einem Atemzug erwähnen. Das eine ist Authentifizierung auf Request-Ebene, das zweite sind Sessions mit (optionaler) Authentifizierung.

HTTP ist ein zustandsloses Protokoll und mit Sessions versucht man dies aufzuheben, indem man mehrere Requests über ein gemeinsames Datum zusammenfasst – die Session-ID.

Die Session-IDs werden serverseitig gespeichert (nicht notwendig, aber üblicherweise) und es können weitere Daten mit ihnen verknüpft sein ($_SESSION bei PHP). Die Session wird also serverseitig erzeugt und kann serverseitig beendet werden. Die verknüpften Daten werden gelöscht werden, sobald die Session beendet wird.

Mit Session-IDs kann man *auch* Authentifizierung umsetzen, muss es aber nicht. Dazu wird ein Loginstatus in der Session gespeichert. Nach erfolgter Anmeldung mit Username/Passwort oder sonst einem Token gelten sämtliche Requests, die die Session-ID übermitteln, als »beglaubigt«.

Das alles gibt es bei HTTP Auth nicht, weil hier eine Authentifizierung für einen einzelnen Request stattfindet. Es wird keine Session erzeugt in dem Sinne, dass statuslose HTTP-Requests einen Status bekommen. (Wenn man einmal von der Nonce bei Digest Auth absieht, die ein gemeinsames Datum zwischen Requests darstellt – diese ist m.W. zufällig und ewig gültig.)

Mathias