nicht angemeldet
Der Martin
molily
molily
molily
molily
Matthias Apsel
Hey,
Ich arbeite an einem Login-Skript in PHP. Dazu benutze ich für die Nutzererkennung Sessions. Dabei wird der Hash des Nutzernamens in einer Session gespeichert. Ich habe gehört, dass Sessions gehijacked werden können. Kann dabei auch der gespeicherte Hash des Nutzernamens entwendet werden. Dies müsste ja serverseitig gespeichert werden. Außerdem möchte ich keine Cookies verwenden. Was glaubt ihr ist generell die bessere Wahl: Session oder Cookies?
Danke im Voraus
Mahlzeit,
Was glaubt ihr ist generell die bessere Wahl: Session oder Cookies?
Ein Session-Cookie ;)
Die Session-ID in der URL mitzuführen bringt einiges an Nachteilen, dazu kannst du einiges im Archiv finden.
Hallo,
Ich habe gehört, dass Sessions gehijacked werden können. Kann dabei auch der gespeicherte Hash des Nutzernamens entwendet werden.
nein, denn Session Hijacking heißt ja nur, dass jemand die Session ID abgreift und dann die Rolle des angemeldeten Nutzers übernehmen kann. Trotzdem kommt er nicht an die in der Session gespeicherten Daten, wenn der Server sie nicht "freiwillig" rausrückt.
Was glaubt ihr ist generell die bessere Wahl: Session oder Cookies?
Nicht oder. Erst beides zusammen ergibt ein gutes Team, da die Session ID meist per Cookie übermittelt wird.
Ciao,
Martin
હેલો
Ich habe gehört, dass Sessions gehijacked werden können.
Du kannst angreifern das leben schwer machen.
બાય
Hallo,
Du kannst angreifern das leben schwer machen.
Inwiefern macht das Angreifern das Leben schwer?
Es vereinfacht den Angriff vielmehr. Sobald ich als Angreifer eine Session-ID ergattert habe, erzeuge ich schnell viele Requests, sodass ich (aufgrund irgendeiner Heuristik) eine neue ID zugewiesen bekomme.
Damit ist es dem tatsächlichen Nutzer nicht einmal mehr möglich auszuloggen. Ich habe die Session komplett übernommen, kann sie am Leben erhalten und der Nutzer ist ausgesperrt.
Mathias
હેલો
Sobald ich als Angreifer eine Session-ID ergattert habe, erzeuge ich schnell viele Requests, sodass ich (aufgrund irgendeiner Heuristik) eine neue ID zugewiesen bekomme.
Das ist doch gut, quasi ein Frühwarnsystem.
Damit ist es dem tatsächlichen Nutzer nicht einmal mehr möglich auszuloggen. Ich habe die Session komplett übernommen, kann sie am Leben erhalten und der Nutzer ist ausgesperrt.
Und sobald ich als Nutzer wie von magischer Hand ausgeloggt werde (weil vmtl. ein technischer Fehler vorliegt), logge ich mich einfach erneut ein und deine ganze arbeit war umsonst, weil ich wieder eine ganz neue Session-ID erzeuge und dich damit aussperre. Und dann geht das Spielchen von vorne los.
Wenn du in der zwischenzeit das Passwort des betroffenen Kontos ändern konntest, weil es mit einer erratenen Session-ID möglich ist, dann ist das System fehlerhaft.
બાય
logge ich mich einfach erneut ein und deine ganze arbeit war umsonst, weil ich wieder eine ganz neue Session-ID erzeuge und dich damit aussperre.
Wie wird das erreicht? Wo ist festgelegt, dass pro User nur eine Session möglich ist und beim Login alle vorherigen Sessions des Users gelöscht werden?
PHP hat standardmäßig keine solche Begrenzung, soweit ich weiß.
Die meisten Systeme haben keine derartige Begrenzung. Sie lassen es vielmehr explizit zu, damit man mit mehreren Browsern und Geräten eingeloggt sein kann.
Ergo: Der Angreifer kann mit der alten Session weiter arbeiten, der User erstellt sich eine neue, zweite.
Wenn du in der zwischenzeit das Passwort des betroffenen Kontos ändern konntest, weil es mit einer erratenen Session-ID möglich ist, dann ist das System fehlerhaft.
Davon habe ich auch nicht gesprochen.
Mathias
હેલો
Wie wird das erreicht? Wo ist festgelegt, dass pro User nur eine Session möglich ist und beim Login alle vorherigen Sessions des Users gelöscht werden?
Hast du geschrieben? Du übernimmst das Konto und sperrst den User dadurch aus. Wenn du durch die übernahme den User aussperren kannst, sollte es doch auch andersherum gehen?
Ergo: Der Angreifer kann mit der alten Session weiter arbeiten, der User erstellt sich eine neue, zweite.
Das ist doch auch der fall, wenn du eine konstante Session-ID hast, statt eine ständig wechselnde. Wo ist der Vorteil, wenn ich eine feste Session-ID nutze?
Ich kann nicht ganz nachvollziehen, wie du jemanden durch die Session-übernahme aussperren kannst?
બાય
હેલો
mein Login kann man auch hijacken, ist aber etwas komplizierter.
PHPSESSID
2dbb1cbc1496bc4185f629e2c1ada4f6
Folgende Cookies hinzufügen:
stuser
3908520+5012d7b2ce92f977f567bedecb1dd4bf
speedtab
1755786577
stayon
true
Pfad: /
Dann sollet ihr als User „test“ eingeloggt sein.
બાય
Meine Herren!
Dann sollet ihr als User „test“ eingeloggt sein.
Ich hab mich ausgeloggt. SCNR.
હેલો
Dann sollet ihr als User „test“ eingeloggt sein.
Ich hab mich ausgeloggt. SCNR.
Hast du nicht, oder?
Könnte mal jemand mit den Daten rein und sich abmelden (oben rechts Symbol hovern und abmelden)? Ich würde gerne wissen, ob ich dadurch auch ausgeloggt werde.
બાય
Meine Herren!
હેલો
Dann sollet ihr als User „test“ eingeloggt sein.
Ich hab mich ausgeloggt. SCNR.
Hast du nicht, oder?
Doch habe ich tatsächlich, aber ich konnte mich auch weitere Male einloggen.
session_regenerate_id() scheint dabei in Gebrauch zu sein, denn jeder Request antwortet mir mit einer neuen Session-ID im Cookie-Header. Aber das delete_old_session-Flag scheint nicht gesetzt zu sein.
Die Cookies habe ich übrigens ganz simpel über die JS-Konsol gesetzt:
document.cookie = "PHPSESSID=2dbb1cbc1496bc4185f629e2c1ada4f6";
document.cookie = "stuser=3908520+5012d7b2ce92f977f567bedecb1dd4bf";
document.cookie = "speedtab=1755786577";
document.cookie = "stayon=true";
હેલો
session_regenerate_id()scheint dabei in Gebrauch zu sein, denn jeder Request antwortet mir mit einer neuen Session-ID im Cookie-Header. Aber das delete_old_session-Flag scheint nicht gesetzt zu sein.
Stimmt, dass habe ich jetzt korrigiert. Könntest du das nochmal versuchen? Eine andere frage wäre auch, ob ich jetzt automatisch ausgeloggt werde, wenn du dich lediglich einloggst?
Die Cookies habe ich übrigens ganz simpel über die JS-Konsol gesetzt:
document.cookie = "PHPSESSID=2dbb1cbc1496bc4185f629e2c1ada4f6";
document.cookie = "stuser=3908520+5012d7b2ce92f977f567bedecb1dd4bf";
document.cookie = "speedtab=1755786577";
document.cookie = "stayon=true";
So einfach hackt man ein Konto ;)
બાય
--
.
..:
Meine Herren!
session_regenerate_id()scheint dabei in Gebrauch zu sein, denn jeder Request antwortet mir mit einer neuen Session-ID im Cookie-Header. Aber das delete_old_session-Flag scheint nicht gesetzt zu sein.Stimmt, dass habe ich jetzt korrigiert. Könntest du das nochmal versuchen?
Habe ich getan, ich kann mich nach wie vor einloggen (mit dem bereits schon genannten JS-Code und anschließendem Refresh). Auch nach einem Logout lässt sich die Prozedur wiederholen.
So einfach hackt man ein Konto ;)
Naja, der schwierigste Teil besteht darin an die Session-ID zu gelangen und die hast du mir immerhin bereitwillig gegeben.
હેલો
Habe ich getan, ich kann mich nach wie vor einloggen (mit dem bereits schon genannten JS-Code und anschließendem Refresh). Auch nach einem Logout lässt sich die Prozedur wiederholen.
Sorry, ich glaube, ich hatte es falsch gemacht. Habe es jetzt vor einer Minute korrigiert. Könntest du noch ein letztes mal?
Soll wohl so sein?
session_regenerate_id(true);
Wie schaffe ich denn, dass wenn du dich ausloggst, ich auch automatisch rausgeschmissen werde?
બાય
Meine Herren!
Sorry, ich glaube, ich hatte es falsch gemacht. Habe es jetzt vor einer Minute korrigiert. Könntest du noch ein letztes mal?
Nope, ich komme immer noch rein. Du solltest die bisherigen Session-Dateien übrigens auch manuell löschen, wenn die Änderungen auch für die alten Sessions wirksam werden sollen.
Wie schaffe ich denn, dass wenn du dich ausloggst, ich auch automatisch rausgeschmissen werde?
Dazu musst du irgend ein Kriterium in der Session mitschleppen, über das ein Nutzer wiedererkannt werden kann, zum Beispiel die Nutzer-ID oder die Credentials. Angenommen der selbe Nutzer hat mehrere Sessions gleichzeitig laufen, dann müsstest du beim Logout alle Sessions durchlaufen, die dem Nutzer zugeordnet sind, und dann jede einzelne zerstören. Ob das wünschenswert ist?
હેલો
Nope, ich komme immer noch rein. Du solltest die bisherigen Session-Dateien übrigens auch manuell löschen, wenn die Änderungen auch für die alten Sessions wirksam werden sollen.
Ich kriege nicht mal den session_save_path angezeigt. Ich kann es auch nicht Manuell setzen, schade.
session_save_path = "/homepages/***/****/htdocs/ypsilon/sesstmp" # php.ini bringt nichts
ini_set('session.save_path',realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/ypsilon/sesstmp')); # auch nicht
Dazu musst du irgend ein Kriterium in der Session mitschleppen, über das ein Nutzer wiedererkannt werden kann, zum Beispiel die Nutzer-ID oder die Credentials.
Die habe ich ja, in der Session sind 4 od. 5 Variablen gespeichert, die mit den Cookies abgeglichen werden.
Angenommen der selbe Nutzer hat mehrere Sessions gleichzeitig laufen, dann müsstest du beim Logout alle Sessions durchlaufen, die dem Nutzer zugeordnet sind, und dann jede einzelne zerstören.
Dann müsste ich erstmal zugriff auf die Session-Dateien haben? Da komme ich anscheinend nicht ran.
Ob das wünschenswert ist?
Ich rätsel noch, ich denke eigentlich nicht. In meinem Fall wäre es eig. nicht wünschenswert, aber schön, wenn ich es zuschalten könnte.
બાય
હેલો
Auch nach einem Logout lässt sich die Prozedur wiederholen.
Dann stimmt doch schon hier etwas nicht? Wenn du dich ausloggst, sollte doch die betroffene Session endgültig gekillt werden? Wieso kommst du mit den alten Daten dann noch rein?
બાય
Hello E.,
Auch nach einem Logout lässt sich die Prozedur wiederholen.
Dann stimmt doch schon hier etwas nicht? Wenn du dich ausloggst, sollte doch die betroffene Session endgültig gekillt werden? Wieso kommst du mit den alten Daten dann noch rein?
Wir müssen wohl nochmal bei Adam & Eve beginnen?
HTTP ist verbindungslos und damit zustandslos
Ein Login gibt es nicht per HTTP, sondern mur eine unsichere Authentifikation
Aus dieser Authentififaktion kan man eine Identifikation betreiben
Das nennt man dann leider "Login", obwohl es sich ur um ein
"Re-Auth mit nachfolgenden Unsicherheiten" handelt
Das Bestehen einer Session (Auth) hat überhaupt nicht zur Folge, dass auch eine
"Anmeldung" (Ident) besteht.
Eine Re-Identifikation setzt eine gültige Session voraus
Es gibt unterschiedliche Verfahren für das vermeintliche "HTTP-Login"
-- sessionbasiert
-- requestbasiert
usw.
Ich werde mich quälen und das im Wiki näher erläutern.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
હેલો
Wir müssen wohl nochmal bei Adam & Eve beginnen?
ich hoffe doch nicht? ;)
Ich war davon ausgegangen, dass bei session_destroy() die betroffene Session auf dem Server endgültig gelöscht wird. Ich komme nicht mal an das Session-Verzeichnis, weiss daher auch nicht, was sich da bereits angesammelt hat.
Was wird denn bei session_destroy() destroyed? Wie wird die denn gekillt, wenn sie auf dem Server nicht gelöscht wird?
બાય
Hello,
Wir müssen wohl nochmal bei Adam & Eve beginnen?
ich hoffe doch nicht? ;)
Ich war davon ausgegangen, dass bei
session_destroy()die betroffene Session auf dem Server endgültig gelöscht wird. Ich komme nicht mal an das Session-Verzeichnis, weiss daher auch nicht, was sich da bereits angesammelt hat.Was wird denn bei
session_destroy()destroyed? Wie wird die denn gekillt, wenn sie auf dem Server nicht gelöscht wird?
*hoppla*
Welche Sessiondatei willst Du denn zerstören, wenn Dir deine letzte bekannte Session geklaut und damit von session_regenerate() umbenannt wurde? Ein [code lang = php] session_desdroy() [/code] sollte ins Leere greifen.
Wenn session_regenerate() nicht benutzt wurde, könnte deine Sessiondatei allerdings noch existieren. Das wäre dann estmal der Normalzustand.
Dann würdest Du aber nicht unbedingt merken, dass dort jemand Trittbrett fährt. Hängt immer von den Applikationen ab.
Erst, wenn der Andere 'was Blödes macht, würdest Du davon Wind bekommen.
Für eine Passwort-Änderung oder sonstige Konfigurationänderungen verlangt der Applikationsanbieter (alöso Du) ja hoffentlich ohnehin das alte Passwort...
Oder die Verbindung war ohnehin verschlüsselt!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
હેલો
Welche Sessiondatei willst Du denn zerstören, wenn Dir deine letzte bekannte Session geklaut und damit von
session_regenerate()umbenannt wurde? Einsession_desdroy()sollte ins Leere greifen.
Dann ist session_regenerate doch eher schlecht. Dadurch erzeuge ich ja unzählige Session-Dateien, damit öffne ich doch unzählige Türen? Mit jeder neu erzeugten Session, also praktisch jedem Request kommt eine neue Tür hinzu? Ich dachte die alten Session-Daten werden gelöscht.
Wenn
session_regenerate()nicht benutzt wurde, könnte deine Sessiondatei allerdings noch existieren. Das wäre dann estmal der Normalzustand.
Aber warum? Wenn ich session_destroy sage, meine ich dass doch auch?
બાય
Du übernimmst das Konto und sperrst den User dadurch aus. Wenn du durch die übernahme den User aussperren kannst, sollte es doch auch andersherum gehen?
Ich verstehe leider nicht, was du damit sagen willst.
Die Übernahme der Session führt nicht notwendig zur permanenten Übernahme des Kontos. Um eine neue Session zu erzeugen, muss der Angreifer immer noch die Login-Credentials habe. (Die E-Mail-Adresse sollte sich natürlich nur mit Passwort ändern lassen, sonst kann der Angreifer einfach die Password-Recovery-Funktion nutzen.)
Wo ist der Vorteil, wenn ich eine feste Session-ID nutze?
Schrieb ich doch: Dass der User ausloggen kann, nachdem Session-Hijacking passiert ist, und damit die Session zerstört.
Mathias
Hello,
logge ich mich einfach erneut ein und deine ganze arbeit war umsonst, weil ich wieder eine ganz neue Session-ID erzeuge und dich damit aussperre.
Wie wird das erreicht? Wo ist festgelegt, dass pro User nur eine Session möglich ist und beim Login alle vorherigen Sessions des Users gelöscht werden?
Das wird in der Spezifikation für die Anwendung festgelegt und der Programmierer hat diese dann umzusetzen ;-P
Und auch wenn mehrere Sessions parallel geführt werden können, gilt eben die Aussage von MB für jede dieser Sessions parallel und gleichzeitig :-)
PHP hat standardmäßig keine solche Begrenzung, soweit ich weiß.
Wenn Du Session per Cookie betreibst, wird es aber schon verflixt schwer, die unterschiedlichen Sessions voneinander zu trennen. Das Problem liegt mMn beim Client: Wieviele Parameter darf eine Cookiedatei aufnehmen pro Domain?
Die meisten Systeme haben keine derartige Begrenzung. Sie lassen es vielmehr explizit zu, damit man mit mehreren Browsern und Geräten eingeloggt sein kann.
Das ist eine Frage der Spezifikation.
Bei der requestbasierten Rechteprüfung (empfohlen!) entfällt diese Möglichkeit von alleine, da sich die Rechte-Requests in den Userdaten konsolidieren und nicht in den Sessions.
Ergo: Der Angreifer kann mit der alten Session weiter arbeiten, der User erstellt sich eine neue, zweite.
Das hängt, wie schon mehrfach erwähnt, ausschließlich von der Spezifikation der Anwendung und dem gewählten Anmelde-Verfahren ab, nicht aber zwingend von PHP oder Perl oder, oder, oder.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi,
Du kannst angreifern das leben schwer machen.
Inwiefern macht das Angreifern das Leben schwer?
Es erschwert zumindest, mittels Session Fixation¹ verwertbare Ergebnisse zu erzielen; sofern es sinnvoll eingesetzt wird, z.B. immer dann, wenn der Benutzer eine Aktion auslöst, die eine Erhöhung seiner Rechte bewirkt (und das kann bspw. auch der simple Wechsel vom Zustand „anonymer Gast“ hin zu „eingeloggter Nutzer“ sein).
(Das heißt aber natürlich nicht, dass man es wahllos bei jedem x-beliebigen Request machen sollte.)
MfG ChrisB
¹ Wobei Session Fixation natürlich in ihrer simplen Variante nur funktioniert, wenn die Übergabe der Session-ID nicht auf Cookies beschränkt wird.
Hello,
Du kannst angreifern das leben schwer machen.
Inwiefern macht das Angreifern das Leben schwer?
Indem die Session-ID schon im nächsten Moment nicht mehr gültig sein kann, da der Eigentümer schneller geklickt hat, als der unrechtmäßige Zweitbesitzer.
Das Ganze ist dann eine Race-Condition.
Das Erraten von konsistenten Sessionnummern wird durch die von MB vorgeschlagene Funktion auf jeden Fall erschwert, denn die gibt es ja dann nicht mehr.
Das Verfahren ist allerdings nicht besonders geschickt, wenn die Webanwendung mit schnellen AJAX-Requests arbeitet, die mMn ja sowieso in die Tonne gehören, aber immer gerne als "Best Practice" verkauft werden :-P
Es vereinfacht den Angriff vielmehr. Sobald ich als Angreifer eine Session-ID ergattert habe, erzeuge ich schnell viele Requests, sodass ich (aufgrund irgendeiner Heuristik) eine neue ID zugewiesen bekomme.
Das ist alles eine Frage von "wie schnell"?
Damit ist es dem tatsächlichen Nutzer nicht einmal mehr möglich auszuloggen.
Da ist ein Denkfehler im System. Der rechtmäßige Besitzer IST DANN "AUSGELOGGED".
Allerdings merkt er es üblicherweise nicht, wenn ein Trittbrettfahrer auf seiner Session mit konsistenter Session-ID herumreitet. Er merkt es aber sofort, wenn ein Trittbrettfahrer auf seiner Session mit wechselnder Session-ID herumreitet. Dann ist nämlich seine eigene Session-ID auf dem Client schon beim nächsten Request ungültig. Er wird sich damit vermutlich neu anmelden und damit kann dann der Dieb mit der von ihm ergatterten SID auch nix mehr anfangen.
Ich habe die Session komplett übernommen, kann sie am Leben erhalten und der Nutzer ist ausgesperrt.
Ausgesperrt ist vollkommen falsch! Siehe oben!
In eine Sessiondatei gehören allerdings keine Credentials!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Indem die Session-ID schon im nächsten Moment nicht mehr gültig sein kann, da der Eigentümer schneller geklickt hat, als der unrechtmäßige Zweitbesitzer.
Das Ganze ist dann eine Race-Condition.
Ja, eben – zugunsten des Angreifers.
Wie gesagt: Der Angreifer wird das automatisieren können, indem er viele Requests startet. Der unbedarfte Nutzer wird beim ganz normalen Surfen auf der Website den kürzeren ziehen.
Da ist ein Denkfehler im System.
Wie gesagt, dass mehrere Sessions pro User existieren können, ist im Jahr 2014 ein wichtiges Feature. Alle Single-Sign-On-Dienste unterstützen das.
Der rechtmäßige Besitzer IST DANN "AUSGELOGGED".
… sofern man den delete_old_session-Flag auf true setzt. Was man tun sollte, sofern man meint, session_regenerate_id könne Sicherheit verbessern.
http://www.php.net/manual/de/function.session-regenerate-id.php#refsect1-function.session-regenerate-id-parameters
Mathias
Hello,
… sofern man den delete_old_session-Flag auf true setzt. Was man tun sollte, sofern man meint, session_regenerate_id könne Sicherheit verbessern.
http://www.php.net/manual/de/function.session-regenerate-id.php#refsect1-function.session-regenerate-id-parameters
Was hat das "delete-old-session-flag" mit der Gültigkeit der Anmeldung am System zu tun?
Das Vorhandensein einer Session hat nichts mit einer gültigen Anmeldung zu tun!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Ich arbeite an einem Login-Skript in PHP. Dazu benutze ich für die Nutzererkennung Sessions. Dabei wird der Hash des Nutzernamens in einer Session gespeichert.
Wieso der Hash des Nutzernamens? (Reden wir über einen Hash als Datenstruktur oder über einen kryptographischen Hash?)
In den Session-Daten, das ist eine Datenstruktur auf dem Server, steht üblicherweise die User-ID. So wird der Login-Status umgesetzt. Den Namen nun zu hashen, gar mit ungesalzenem MD5 oder ähnlich, ist unnötig und verbessert die Sicherheit nicht.
Ich habe gehört, dass Sessions gehijacked werden können. Kann dabei auch der gespeicherte Hash des Nutzernamens entwendet werden.
Die Session-Daten befinden sich üblicherweise auf dem Server. Ein direkter Zugriff darauf ist nicht durch Session-Hijacking möglich, sondern höchstens durch einen Einbruch in die Server-Software.
Ein Angreifer kann mit der Session jedoch alles tun, was der eingeloggte User tun kann. Es kann also alles entwendet werden, das dein System dem eingeloggten User herausgibt.
Ich bin mir ziemlich sicher, dass der Nutzername dazugehört, weil der i.d.R. auf der generierten Website steht. Ich bin mir auch sicher, dass der Nutzername zu den Informationen gehört, deren Kompromittierung am wenigsten schmerzhaft ist. Die anderen Informationen und Funktionen, auf die der Angreifer durch das Session-Hijacking Zugriff hat, sind wahrscheinlich das größere Problem.
Außerdem möchte ich keine Cookies verwenden.
Warum nicht?
Was glaubt ihr ist generell die bessere Wahl: Session oder Cookies?
Die Frage ist unlogisch, weil Cookies ein Mittel sind, um Sessions umzusetzen; und Sessions sinnvollerweise mit Cookies gelöst werden. Eine andere sichere und zuverlässige Möglichkeit, Session-Identifier bzw. Session-Daten zu übertragen, gibt es nicht.
Mathias
Hello,
Die Session-Daten befinden sich üblicherweise auf dem Server. Ein direkter Zugriff darauf ist nicht durch Session-Hijacking möglich, sondern höchstens durch einen Einbruch in die Server-Software.
... durch falsch eingerichtete Systeme bei Shared Hosting.
Dort ist dann ggf. der Zugriff auf Sessiondateien anderer Realms möglich.
Mit Vorliebe passiert das, wenn PHP auf dem Apachen als Modul eingerichtet wird und nicht für jeden VirtHost ein eigenes Session-Verzeichnis eingerichtet wird.
siehe "session.save_path"
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Meine Herren!
Das Thema hatten wir neulich erst:
http://forum.de.selfhtml.org/archiv/2014/2/t216607/#m1485575
http://forum.de.selfhtml.org/archiv/2014/2/t216607/#m1485573
Ich denke, diese beiden Beiträge umreißen die zu Grunde liegende Problematik ganz gut.
Hello,
Ich arbeite an einem Login-Skript in PHP. Dazu benutze ich für die Nutzererkennung Sessions.
[...]
Ich dachte, dass andere Poster und ich meine Gedanken dazu scho ausreichend hier niedergeschrieben hätten, aber vermutlich hat Matthias recht und wir müssen diese Gedanken aus dem Archiv einsammeln, sortieren und als Wiki-Beitrag miederschreiben. Das macht man leider nicht einfach so in fünf Minuten.
Zuvor bitte nur nochmal eins:
HTTP kennt kein "Login", da es Zustandslos arbeitet. Wenn ein request abgeschlossen ist, also durch abschließende Response beantwortet wurde, haben Server und Client keine Verbindung mehr untereinander.
Wenn wir nun trotzdem ein "Login" emulieren wollen , dann besteht das aus
Wir müssen also mindestens drei Stufen voneinander trennen:
Manche Anwendungen sch(m)eißen das leider ohne nachzudenken in einen Topf.
Ich wiederhole mich daher hier nochmal:
Eine Session zum Server zu haben, bedeutet nicht, an diesem Rechte wahrnehmen zu dürfen!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Meine Herren!
Es gibt bereits einen Artikel zum Thema http://wiki.selfhtml.org/wiki/Technische_Ergänzungen/Loginsystem, vielleicht kannst du dich da ja mit einbringen.
Hello,
Es gibt bereits einen Artikel zum Thema http://wiki.selfhtml.org/wiki/Technische_Ergänzungen/Loginsystem, vielleicht kannst du dich da ja mit einbringen.
Das weiß ich.
Wenn der Autor nicht beleidigt ist, wenn wir den in mehrere Teile zerlegen
dann wäre ich gerne dabei, Teil 1 und 3 zu erstellen. Sie habe ich hier im Forum in Fragmenten ohnehin schon mehrfach verbreitet.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
- (1) Login unter HTTP, generelle Betrachtung
- (2) sessionbasiert (einfach)
- (3) requestbasiert (...)
dann wäre ich gerne dabei, Teil 1 und 3 zu erstellen.
Und was ist ein »requestbasierter« Login?
Tipp fürs Editieren des Wikis:
Keine Theoriefindung
Mathias
Hello,
Und was ist ein »requestbasierter« Login?
Tipp: benutze bitte die Archivsuche:
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Da es nur ein Treffer gibt, meinst du wohl:
</archiv/2014/1/t216393/#m1483964>
Was hat ein »Wer ist online«-Feature damit zu tun, wie man grundsätzlich ein Loginsystem baut? Das ist eine zusätzliche Technik, die natürlich auf Sessions aufsetzt. Stoff für einen zweiten Artikel.
Ich will niemanden davon abhalten, am Wiki zu arbeiten, aber bestehende Artikel sollte man nicht verwässern, indem man sie um Infos ergänzt, die nur entfernt zum Thema gehören.
Mathias
Hello,
Da es nur ein Treffer gibt, meinst du wohl:
</archiv/2014/1/t216393/#m1483964>Was hat ein »Wer ist online«-Feature damit zu tun, wie man grundsätzlich ein Loginsystem baut?
Du kannst Die Funktion ja einfach weglassen, wenn Du sie nicht magst.
Das ist eine zusätzliche Technik, die natürlich auf Sessions aufsetzt. Stoff für einen zweiten Artikel.
Genau. Und die ist mit einem sessionbasierten Login gar nicht möglich.
Dir scheinen die Begriffe "requestbasiert" und "sessionbasiert" Probleme zu bereiten. Die haben hier nichts damit zu tun, dass man für beide Verfahren eine Session als Basis benötigt.
"sessionbasiert":
Die authentifikation des Users findet nur einmal pro Session statt.
Ein Admin sieht nicht, wer "angemeldet" ist, da er i.d.R. die Sessionnummer eines Users nicht kennt. Die Rechte des Users werden üblicherweise auf nur einmal pro Session geprüft und haben dann über die ganze Session Bestand.
"requestbasiert":
Bei jedem Request wird der Status des Users gegengeprüft.
Das führt dann auch dazu, dass die allmeinen Rechte bei jedem Request erneut geprüft werden können. Ein Admin (oder wer auch immer) kann nun auch sehen, wer "angemeldet" ist. Das bedeutet bei HTTP ja nur, dass innerhalb einer gewissen Zeitspanne ein Request stattgefunden hat. Er kennet aber jtzt die Sessionnummer des Users und kann ihn auch jederzeit "rausschmeißen".
Ich will niemanden davon abhalten, am Wiki zu arbeiten, aber bestehende Artikel sollte man nicht verwässern, indem man sie um Infos ergänzt, die nur entfernt zum Thema gehören.
Da wird nichts verwässert. Anders ist eben anders. Selber lesen und Denken wird durch eine zweite Möglichkeit nicht ersetzt.
Ich rede Dir im Übrigen auch nicht in deine mMn sehr qualifizierten Tipps zum Thema JavaScript rein ;-P
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Dir scheinen die Begriffe "requestbasiert" und "sessionbasiert" Probleme zu bereiten. Die haben hier nichts damit zu tun, dass man für beide Verfahren eine Session als Basis benötigt.
Ja, ich störe mich an den Begriffen, weil sie untauglich und verwirrend sind.
Ein Login ist üblicherweise sessionbasiert. Beim Login wird eine Session gestartet. Bei jedem Request wird serverseitig überprüft, ob unter der im Request angegeben Session-ID gespeichert ist, das eine Authentifizierung stattgefunden hat.
Die Gegenüberstellung von sessionbasiertem vs. requestbasiertem Login halte ich für Quatsch. Dies ist kein etablierter Begriff. Wenn ich danach google, finde ich nur dein Posting. -> Theoriefindung.
Dir scheinen die Begriffe "requestbasiert" und "sessionbasiert" Probleme zu bereiten. Die haben hier nichts damit zu tun, dass man für beide Verfahren eine Session als Basis benötigt.
"sessionbasiert":
Die authentifikation des Users findet nur einmal pro Session statt.
(...) Die Rechte des Users werden üblicherweise auf nur einmal pro Session geprüft und haben dann über die ganze Session Bestand.
"requestbasiert":
Bei jedem Request wird der Status des Users gegengeprüft.
Das ist unlogisch.
Die Authentifizierung besteht i.d.R. im Übermitteln von Username und Password. Das findet bei den üblichen Weblogins immer nur einmal statt.
Bei HTTP Basic Auth hingegen gibt es tatsächlich eine requestbasierte Authentifizierung. WEIL ES EBEN KEINE SESSION GIBT.
In DIESEM Sinne halte ich es für sinnvoll, von session- vs. requestbasierter Authentifizierung zu sprechen.
Wenn du jetzt sagst, dass beide Verfahren auf Sessions basieren, so ist das eine unbrauchbare und untypische Terminologie.
"sessionbasiert":
Ein Admin sieht nicht, wer "angemeldet" ist, da er i.d.R. die Sessionnummer eines Users nicht kennt.
Natürlich kann der Admin sehen, wer »angemeldet« ist (definiert als: welche User eine aktive Session haben). Dazu muss er nur alle Sessions durchgehen und nach dem Usernamen filtern. Das ist auch in PHP möglich, schließlich sind Sessions nur Dateien. Die Sessions in einer Datenbank zu speichern, macht den Zugriff nur einfacher. Es ist aber kein qualitativer Unterschied!
"requestbasiert":
Bei jedem Request wird der Status des Users gegengeprüft.
Das führt dann auch dazu, dass die allmeinen Rechte bei jedem Request erneut geprüft werden können.
Häh? Das geht natürlich auch bei ganz normalen Sessions, indem man prüft, ob der User gewisse Rechte hat. Das wird auch ständig getan. Dazu hat ein User meistens irgendwelche Capabilities, z.B. Lese- oder Schreibrechte auf einen gewissen Entity. Das löst man i.d.R. relational mit Rechtetabellen.
Ein Admin (oder wer auch immer) kann nun auch sehen, wer "angemeldet" ist.
Wie gesagt, das ist ein spezielles Feature, das mit Logins und Sessions erst einmal nichts zu tun hat.
Er kennet aber jtzt die Sessionnummer des Users und kann ihn auch jederzeit "rausschmeißen".
Das ist auch mit normalen Sessions möglich.
Das Big Picture ist: Es gibt tausende Arten, auf dem Server Sessions zu speichern. In Dateien, Datenbanken oder gar nicht (verschlüsselt im Cookie). Die meisten davon erlauben es ohne weiteres, die offenen Sessions für einen User zu finden. Dein Beispielcode erzeugt nur eine weitere Tabelle, die den Zugriff im Falle von dateibasierten Standard-PHP-Sessions vereinfacht.
Ich rede Dir im Übrigen auch nicht in deine mMn sehr qualifizierten Tipps zum Thema JavaScript rein ;-P
Ich hingegen rede dir in deine unqualifizierten Tipps zum Thema Sessions hinein.
Wie auch immer: Schreibe deinen Artikel und stelle ihn der breiteren Öffentlichkeit zur Diskussion.
Mathias
Hello,
Dir scheinen die Begriffe "requestbasiert" und "sessionbasiert" Probleme zu bereiten. Die haben hier nichts damit zu tun, dass man für beide Verfahren eine Session als Basis benötigt.
Ja, ich störe mich an den Begriffen, weil sie untauglich und verwirrend sind.
Nein, die sind Top! Nur deine Vorstellung davon ist untauglich. Löse dich einfach davon, dass Deine eigene Vorstellung die einzig richtige ist :-)
Diese Begriffe gibt es schon lange vor dem Internet und Wikipedia. Sollte ich also mal wieder in die UB in Braunschweig oder in Göttingen kommen, dann werde ich versuchen, dort ein Vorkommen lange vor Sir Tim, dem Internet und Wikipedia herauszusuchen. Novell hat sich in den Betrachtungen zum Login im ELS-II bereits lang und breit darüber ausgelassen.
http://en.wikipedia.org/wiki/NetWare
Hier fehlen dann die Papierquellen, die ich selber aber ggf. noch in irgend einer Kiste vor sich hingammelnd stehen habe...
Alles, was Du hier weiter von Dir gibst, ist äußerst spartanisch und leider ohne Backround.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Meine Herren!
Alles, was Du hier weiter von Dir gibst, ist äußerst spartanisch und leider ohne Backround.
Ad hominem ist hier völlig unangebracht.
Hello,
Alles, was Du hier weiter von Dir gibst, ist äußerst spartanisch und leider ohne Backround.
Ad hominem ist hier völlig unangebracht.
Ack
Bitte aber auch den Vorposter auf dieses Verhalten hin analysieren.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello 1UnitedPower,
die Umschaltung auf "zu diesem Forum" bedeutet, dass mit der Forumssoftware, mit den Themenbereich, mirt den Links im Internet usw. etwas nicht stimmt, oder Du einfach eine neue creative Idee zu Forum hattest.
Wenn Du mich (als Poster) kritisieren willst, fällt das bitte unter "Menschelei".
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Meine Herren!
Wenn Du mich (als Poster) kritisieren willst, fällt das bitte unter "Menschelei".
Da bin ich anderer Meinung, "Zu diesem Forum" umfasst für mich nicht nur technische Belange des Forums, sondern auch Belange in Hinsicht auf das Verhalten in diesem Forum. Es ist hier an der Tagesordnung Doppelpostings, Crosspostings oder Vollzitate in diese Kategorie zu gliedern, das Anprangern unseriöser Diskussionsführung ordne ich auch dort ein und das werde ich auch in Zukunft so handhaben. Du darfst es gerne anders machen.
Hello,
Dir scheinen die Begriffe "requestbasiert" und "sessionbasiert" Probleme zu bereiten. Die haben hier nichts damit zu tun, dass man für beide Verfahren eine Session als Basis benötigt.
Ja, ich störe mich an den Begriffen, weil sie untauglich und verwirrend sind.
Ein Login ist üblicherweise sessionbasiert. Beim Login wird eine Session gestartet.
Du bringst die Begriffe und ihre Abhängigkeiten durcheinander.
Wie ist es denn beim HTTP-Basic-Auth?
Das ist ein "Login". Aber wird da eine Session gestartet?
NEIN!
Dort wird temporär Zugang gewährt.
Ich will dir nochmal sie Chance geben, wirklich basisorientiert über die Zusammenhänge nachzudenken, bevor ich hier eine "Session" draus mache.
Und bedenke dabei bitte auch, dass HTTP verbindungslos und damit zustandslos definiert ist. Alle Begriffe, die wir hier im Bezug auf Networking benutzen, sind daher ohnehin nur als Pseudonyme zu betrachten, also eigentlich erstmal auf ihre Grundformen zurückzuführen.
Wenn wir heute also unter HTTP von einer Session sprechen, ist das ohnehin eine Krücke. Denn die Session unter HTTP ist lediglich emuliert.
Wenn wir generell von "sessionbasiert" sprechen, dann bedeutet das, dass alle Bezugsgrößen sich auf den Zeitrahmen der Session beziehen, also vom Beginn bis zum Ende der Session gelten.
Wenn wir von "requestbasiert" sprechen, dann bedeutet das, dass alle Bezugsgrößen pro Request neu bestimmt werden, also nicht für die Dauer einer "Session" gelten.
Man kann nun auch Mischformen erzeugen. Ein "requestbasiertes" Login kann durchaus zur Vereinfachung auf einer Session basieren.
Es kann aber auch ohne jegliche "Session" realisiert werden. Dann müssten die Credentials (also mindestens zwei Schlüssel) jedes Mal neu und gemeinsam übertragen werden.
Ich beweifele hier jetzt mal ganz provokativ, dass Du sich überhaupt mit (meinen|den) Gewdanken zum Thema auseinandersetzen willst. Sonst würdest Du gezielt Fragen zu bestimmten Gedankenschritten stellen und nicht rigoros behaupten, das das alles "untauglich" ist.
Lies dich bitte einwenig besser ein in die Geschichte des Networking (EDV, IT,), bevor Du mir hier Generalschelte verpasst.
Und das meine ich durchaus freundschaftlich!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Meine Herren!
Und bedenke dabei bitte auch, dass HTTP verbindungslos und damit zustandslos definiert ist.
Verbindungslos und zustandslos haben völlig unterschiedliche Bedeutungen. Die "Verbindung" findet im OSI-Schichtenmodell in der Transportschicht ihren Gebrauch, der "Zustand" dagegen auf der Anwendungsschicht. Insbesondere folgt das eine nicht aus dem anderen.
Wenn wir heute also unter HTTP von einer Session sprechen, ist das ohnehin eine Krücke. Denn die Session unter HTTP ist lediglich emuliert.
Emuliert halte ich für irreführend, obwohl ich nachvollziehen kann, worauf die hinaus möchtest. HTTP impliziert keine Zustände über mehrere Round-Tunrs, aber es schließt sie auch nicht aus: nur HTTP sieht sich selbst nicht verantwortlich dafür, es versucht allgemeiner, umfassender zu sein und die Erfinder haben deshalb sinngemäß beschlossen: "Nope, das ist Teil einer höheren Anwendungsschicht, damit haben wir nichts zu tun". HTTP(S) erlaubt aber explizit die Implementation von Zuständen über mehrere Round-Turns, sei es durch die Übermittlung einer Session-ID über Cookies oder GET-Parameter oder beispielsweise über HTTPS Client-Zertifikate.
Lies dich bitte einwenig besser ein in die Geschichte des Networking (EDV, IT,), bevor Du mir hier Generalschelte verpasst.
Imaginärer Themenwechsel zu "Menschelei": Sind die Hinweise in de Klammern dein Ernst? Die Abkürzungen taugen vielleicht, um Dialoge für NCIS zu skripten, aber hier kann man sie sich getrost sparen.
Hello,
Und bedenke dabei bitte auch, dass HTTP verbindungslos und damit zustandslos definiert ist.
Verbindungslos und zustandslos haben völlig unterschiedliche Bedeutungen.
Klar. Ich ergänze insofern:
Und bedenke dabei bitte auch, dass HTTP verbindungslos und damit zunächst auch zustandslos definiert ist.
Ohne Vebindung kein Zustand.
Wir die Verbindung nun (z.B. per TCP) emuliert, kann auch ein Zustand emuliert werden.
Das hat aber immer noch nichts mit der Session in PHP zu tun, denn die wird erst auf der Anwendungsschicht emuliert.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Meine Herren!
Und bedenke dabei bitte auch, dass HTTP verbindungslos und damit zustandslos definiert ist.
Verbindungslos und zustandslos haben völlig unterschiedliche Bedeutungen.
Klar. Ich ergänze insofern:
Was ergänzt du wozu? Sorry, das ist mir nicht klar geworden.
Und bedenke dabei bitte auch, dass HTTP verbindungslos und damit zunächst auch zustandslos definiert ist.
Ohne Vebindung kein Zustand.
Das ist in beide Richtungen einfach falsch. HTTP wird in aller Regel über TCP übertragen, und TCP ist definitiv verbindungsorientiert. Und auch verbindungslose Protokokolle wie UDP erlauben Zustände, so etwa SIP. Verbindungen und Zustände, wie sie in der Netzwerk-Terminologie allgemein gebräuchlich sind, sind keine konkurrierenden Techniken.
Wir die Verbindung nun (z.B. per TCP) emuliert, kann auch ein Zustand emuliert werden.
Was verstehst du bitte unter Emulation? In der Netzwerk-Terminologie ist das kein gebräuchlicher Ausdruck.
Das hat aber immer noch nichts mit der Session in PHP zu tun, denn die wird erst auf der Anwendungsschicht emuliert.
Sag das e-Wort nicht immer. HTTP und PHP sind beide in der OSI-Anwendungsschicht angesiedelt. Deine Antwort überschlägt sich in einigen Punkten, das macht es schwierig darauf gezielt einzugehen, deshalb die vielen Nachfragen.
Meine Herren!
HTTP und PHP sind beide in der OSI-Anwendungsschicht angesiedelt.
Diesen Satz bitte ersatzlos streichen.
Moin,
Ein Login ist üblicherweise sessionbasiert. Beim Login wird eine Session gestartet.
ansich korrekt, aber es wird nicht zwingend eine Session auf dem eigentlichen Webserver/Applikation erzeugt. Es können vorgeschaltete Systeme zur Authentifizierung, Authorisierung und Verifizierung bestehen (Serverfarm, OAuth, Authentication Services etc.).
Solche Systeme prüfen bei einem eingehenden Request seine Gültigkeit (Authentication, Authorization allgemein). Die eigentliche Authorizierung für eine bestimmte Anwendung erfolgt in der Regel auf dem eigentlichen Webdienst bzw. dem zugrundeliegendem System. Erst dann wird eine Session mit diesem Dienst, von diesem Dienst, für diesen Dienst, erzeugt.
Möglicherweise hält der Dienst aber gar keine Sessions und operiert anhand von "View-States" und vertraut einfach dem vorgeschalteten Systemen zur Authentifizierung und Authorisierung.
Gruß
Om nah hoo pez nyeetz, 1UnitedPower!
Es gibt bereits einen Artikel zum Thema http://wiki.selfhtml.org/wiki/Technische_Ergänzungen/Loginsystem, vielleicht kannst du dich da ja mit einbringen.
und auch schon eine erneuerte Variante sowie die Diskussion dazu archiv/2013/10/t215374/
Matthias
