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

Beitrag lesen

Hello,

Der "Loginstatus" muss nicht in die Sessiondatei geschrieben werden.

Muss man nicht – habe ich auch nicht behauptet –, aber üblich ist es. Dafür sind Sessions gedacht.

Man kann ihn auch bei jedem Request neu ermitteln, z.B. mit Hilfe der Datenbank.

Man kann sich auch auf den Kopf stellen und dabei eine Limo trinken.

Nun sei doch nicht gelich beleidigt, weil ich hier gegen die irrige Meinung auftrete, dass ein "Logged-Flag" in die Sessiondatei gehören würde. Das hast Du dir doch auch nicht ausgedacht, sondern wiederholst es nur, weil Du bisher nix anderes kennengelernt hast :-P

Das ist zu empfehlen, da man dadurch requestbasiert reagieren kann und nicht nur sessionbasiert.

Diese Unterscheidung halte ich für verwirrend – das hatten wir bereits und ich habe alles nötige dazu gesagt.

Requestbasiert: gilt pro Request
Sessionbasiert: gilt für die ganze Session.

Darüber haben die damals bei Novell ganze Bücher geschrieben.
(Ich hab's mir also auch nicht selber ausgedacht) :-)

Nur weil PHP auf Anhieb keine Funktionen dafür bereit stellt, kann man nicht behaupten "das gibt es nicht".

Nein, es ist KONZEPTIONELL nicht möglich, dass HTTP Auth die BESAGTEN Eigenschaften von Sessions erfüllt. Welche und warum, habe ich beschrieben. Ich werde es nicht wiederholen, da ich mich, wie ich finde, recht klar ausgedrückt habe.

Nein, Du bist einfach nur beleidigt.

Nach deiner Lesart kann aber der PHP-Sessionmechanismus (das ist noch keine Session!) konzeptionell auch nicht die "besagten" Eigenschaften von HTTP-Auth erfüllen, denn mit einem Aufruf von "session_start()" habe ich noch lange keine Authorisierung durchgeführt.

Andersherum habe ich mit einer Anmeldung per HTTP-Auth aber sowohl eine Authentifizierung als auch eine Authorisierung, aber noch keine Session-DATEI. Die kann ich aber sehr wohl "zu Fuß" anschließen, da ich ja weiß, wem die Daten gehören, die da übermittelt werden.

Selbstverständlich kann man auch auf Auth-Basic eine Session aufbauen.

Das wäre eine »Session«, die nie wirklich anfängt und nie wirklich endet. Der Anfang wäre der erste authentifizierte Request, das Ende kann höchstens heuristisch mit einem Timeout bestimmt werden. Ein aktives Beenden der Session ist nicht möglich, wie du auch schreibst.

Das ist in erster Linie ein Manquo der Browser. Und auf dem Server kann man sehr wohl die Authorisierung beenden. Damit wäre dann auch die Session zuende. Es ist aber äußerst unpraktisch für den User. Der benötigt dann nämlich ein neues Passwort. Und das schrieb ich auch!

Also ist es keine wirkliche Session, sondern bloß ein Log, das den letzten authentifizierten Request verzeichnet.

Das verstehe ich jetzt nicht. Was ist nur ein Log?

Eine "wirkliche Session" gibt es in der "verbindungslosen" Kommunikation sowieso nicht. Dort werden nur einzelne Nachrichten verschickt. Es gibt keinen Träger, keine Stromschleife oder ähnliche Mittel, durch die man physisch erkennen kann, dass die Verbindung gekappt wurde.

Eine "wirkliche Session" ermöglicht dem Server die Feststellung _angemeldeter_ Benutzer, also mit aktiver Session. Eben dies ist bei HTTP nicht möglich. Welche Vorgehnesweise nun "stateful" ist, können wir ja nochmal zur Diskussion ausschreiben.

Die Verwendung eines Auth-Tokens ist ein eleganter Ersatz für Username/Passwort.

Für Mitlesende, die sessionbasierte Logins umsetzen wollen, sind solche praxisfernen, rein hypothetischen Diskussionen bloß verwirrend. Noch einmal: HTTP Auth ermöglicht Authentifizierung, aber keine Sessions im besagten Sinne.

Das ist absolut nicht praxisfern. Du verstehst es nur nicht.

Und außerdem möchte ich nochmals daran erinnern, dass es darum ging, Cookies zu verwenden, oder nicht. Und ich habe den Zweig "Session mit HTTP-Auth" nur erwähnt, weil es sehr wohl möglich ist, eine Session damit zu betreiben. Dass es unsicherer ist, Auth-Daten direkt für die "Verbindungserkennung" zu benutzen, habe ich auch erwähnt. Das führt dann zum Auth-Token.

Dass die Browser die Crendetials auch ohne Aufforderung ständig weitersenden und keine Möglichkeit der Löschung im Cache vorsehen, ist ein konzeptioneller Fehler der Browser, nicht der Server.

Und außerdem könnte man auch bei HTTP-Auth auf ein Token wechseln. Der eigentlich "geschützte Bereich" kann ja ganz woanders zu finden sein, als die Anmeldung.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

--
 ☻_
/▌
/ \ Nur selber lernen macht schlau
http://bikers-lodge.com