Session Handling bei Passwortänderung

[Rolf B]

Hallo alle,

wir werden im Moment von einem "Bug Bounty Hunter" mit Mails bombardiert, der behauptet, eine schreckliche Sicherheitslücke im Wiki gefunden zu haben: Wenn ich von zwei Browsern aus mit dem gleichen User angemeldet bin und im Browser A mein Passwort ändere, bleibe ich im Browser B angemeldet. Jo. Ist so. Bugs Bounty meint, man müsse korrekterweise bei einer Passwortänderung alle Fremdsessions invalidieren. Kann man sicherlich machen. In einer High Security Site.

Das Problem besteht solange, bis ich den Browser schließe, danach ist der Session-Keks weg. Ein "angemeldet bleiben" greift nach Passwortänderung nicht mehr.

Natürlich kann ich in den Dev-Tools aus dem Session-Keks einen dauerhaften Keks machen. Dann kann ich den Browser schließen, wieder öffnen und die Session ist immer noch da (es sei denn, ich warte bis zum Session-Timeout, bevor ich den Browser wieder starte). Der Session-Timeout ist nicht allzulang (den genauen Wert kenne ich gerade nicht, aber unter einer Stunde).

Nun haben wir kein Bounty-Programm ausgelobt. Der Typ drängt sich also auf und wenn man so im Netz guckt, werden etliche Leute auf diese Weise genervt. Insofern antworte ich einfach nicht. Im Moment verlangt er noch kein Geld, sondern fragt nur einmal pro Woche, wie denn der Stand der Dinge sei und dass er eine lange Liste mit weiteren Vulnerabilities habe. Was schon nervig genug ist. Heute kam eine gleichlautende Mail von einer anderen Mailadresse - sprich: das ist nicht nur Scam, sondern auch Spam.

Aber mal unabhängig von Spam oder Scam - wie seht ihr diese Lücke? Ist sie ernst zu nehmen? Wie gravierend muss man das für eine Seite wie das Self-Wiki einschätzen? Im Homebanking würde ich sagen: sehr gravierend. Aber selbst die "große Wikipedia" hat diesen Fehler, d.h. er ist in den letzten Mediawiki-Versionen nicht behoben worden.

Nachtrag: und unser Forum hat ihn auch. Selbst wenn ich den Browser schließe und neu öffne, lässt mich die "Angemeldet bleiben" Funktion eingeloggt, obwohl das Passwort geändert wurde. Hm. @Christian Kruse, wie siehst Du das?

Rolf

[Auge]

Hallo

Wenn ich von zwei Browsern aus mit dem gleichen User angemeldet bin und im Browser A mein Passwort ändere, bleibe ich im Browser B angemeldet. Jo. Ist so. Bugs Bounty meint, man müsse korrekterweise bei einer Passwortänderung alle Fremdsessions invalidieren. Kann man sicherlich machen. In einer High Security Site.

Das Problem besteht solange, bis ich den Browser schließe, danach ist der Session-Keks weg. Ein "angemeldet bleiben" greift nach Passwortänderung nicht mehr.

… unabhängig von Spam oder Scam - wie seht ihr diese Lücke? Ist sie ernst zu nehmen? Wie gravierend muss man das für eine Seite wie das Self-Wiki einschätzen?

Prinzipiell ist es für einen Angreifer, mit vorheriger Kenntnis der (bisherigen) Zugangsdaten, auf diese Weise möglich, das Passwort zu ändern und sich damit exklusiven Zugang zum Account zu verschaffen, ohne, dass der eigentliche Besitzer des Accounts das zeitnah mitbekommt, weil dieser ja mit seiner bestehenden Anmeldung/Session (vorerst) weiterhin Zugriff auf seinen Account hat. Dass jemand anderes Zugriff auf den Account hat, fällt erst auf, wenn die bisherigen Zugangsdaten nicht mehr für eine Anmeldung genutzt werden können oder, wenn der Angreifer auffällige Dinge mit dem Account veranstaltet.

Habe ich das so richtig verstanden?

Man könnte jetzt argumentieren, dass im Wiki jede Änderung zurückgerollt werden kann, dass das also „nur“ Arbeit verursacht. Man könnte aber auch argumemtieren, dass das potentiell zu viel Arbeit verursacht. Spam-Wellen mit komplett veränderten Wiki-Seiten hatten wir ja schon, wenn ich mich recht erinnere. Auch mit Klagen über den Aufwand bei der Bereinigung des Spams.

Ob die Wahrscheinlichkeit eines solchen Angriffs^[1] hoch genug ist, um den Aufwand der Fehlerbehebung allein für das SelfWiki mit wiederkehrenden Anpassungen bei möglichen Upgrades der MediaWiki-Installation zu rechtfertigen, kann ich nicht beurteilen.

… selbst die "große Wikipedia" hat diesen Fehler, d.h. er ist in den letzten Mediawiki-Versionen nicht behoben worden.

Naja, das macht es nicht besser. Eine Behebung auf der Seite von Mediawiki wäre natürlich zu bevorzugen. Dann wäre das in der Software drin und man müsste sich nicht bei jedem Update um das Einpflegen der eigenen Code-Zusätze kümmern.

Tschö, Auge

---

1. Ich gehe hier von der Passwortänderung durch jemanden, der nicht der Accountinhaber ist, aus. Wenn hingegen der Account-Inhaber selbst das Passwort in Browser A ändert und bei ihm selbst in Browser B die mit dem alten Passwort gestartete Session weiterläuft, würde ich nicht von einem Angriff sprechen wollen. ↩︎

[Raketenwilli]

Aber mal unabhängig von Spam oder Scam - wie seht ihr diese Lücke? Ist sie ernst zu nehmen?

Naja. Wenn ein Benutzer das Passwort ändert, damit nicht ein Dritter, der - ganz gleich, ob legal oder nicht - an das Passwort gelangt ist, unter seinem Name Beiträge editiert, dann ist die Situation „mindestens unschön“.

Wie gravierend muss man das für eine Seite wie das Self-Wiki einschätzen?

Wie schon geschrieben: „mindestens unschön“. Es stellt sich die Frage nach den möglichen Folgen. Die muten hier erst einmal als „eher gering“ an.

Wenn es einfach (z.B. via eines Inklude/AddIn - z.B. durch Hinzufügen einer oder weniger Datei(en) in ein Verzeichnis) ist, bei einer Passwortänderung alle Sessions des betroffenen Benutzers zu killen und wenn dabei nicht die Gefahr besteht, dass andere Löcher geöffnet werden, dann sollte man das wohl machen.

Ansonsten kann man bei diesem Problem wohl warten, was die Macher des Media-Wiki „austun“.

---

Nachricht des Tages ;-)

[Felix Riesterer]

Lieber Rolf,

wenn ein Mensch an zweierlei Clients jeweils mit einem Session-Keks ausgerüstet eine stehende Anmeldung hat, dann will der das so haben. Soweit so gut.

Wenn der Mensch sein Passwort ändert, dann kann man auf zweierlei Arten argumentieren:

1. Eine Passwortänderung ändert nur das Passwort. Sessions bleiben unverändert.
2. Eine Passwortänderung soll mögliche Missbraucher einer geklauten Session aussperren. Bestehende Sessions werden gekillt, mit Ausnahme derjenigen, in der die Änderung erfolgt ist.

Beide Argumentationen haben meiner Meinung nach ihre validen Anwendungsfälle. Es sollte auf der PW-Änderungsseite eine Checkbox geben, die dem Menschen die Wahl zwischen den beiden Möglichkeiten lässt.

Liebe Grüße

Felix Riesterer

[JürgenB]

Hallo Rolf,

wenn ich das richtig verstanden habe, geht es darum, dass bei einem gehacktem Account

• Hacker und User gleichzeitig eingelockt sind,
• und der Hacker das Passwort ändert, ohne dass es der User mitbekommt, obwohl er gerade auch eingelockt ist.

Dieses Problem sollte man in unserem Fall nur beheben, wenn es (ganz) wenig Aufwand bedeutet.

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

oder andersrum: der User ändert sein Passwort, weil er es für kompromittiert hält, und der Hacker hat trotzdem noch Zugriff, bis seine Session abläuft (ob der dafür nun die Session oder das Passwort oder einen PC mit Daueranmeldung geklaut hat, ist dabei unerheblich).

Im Wiki würde ich das nur in Form eines Bug-Reports an Mediawiki adressieren. Aber ich denke, die bekommen eh schon ähnliche Mails.

Im Forum kann Christian das möglicherweise einbauen. Sofern man es für nötig hält.

Aber meine Frage war ja eher: Ist das ein relevanter Bug oder ist das die Wichtigmacherei eines geldgeilen Spammers? Es ist ja selbst unter Windows so: Ändere ich mein Passwort, fliege ich nicht automatisch aus allen Sessions raus, die mit diesem User aufgebaut wurden.

Der größere Bug besteht übrigens im Verhalten des "angemeldet bleiben" Häkchens. Damit kriege ich einen Cookie, der mir ohne Passworteingabe eine eingeloggte Session beschert. Und auch dieser Cookie bleibt nach Passwortänderung gültig!

Felix' Idee einer Wahlmöglichkeit gefällt mir da eher weniger. Ob man Sessions nach Passwortänderung invalidiert, ist das Ergebnis eines Security-Assessments der betreffenden Site, keine Entscheidung des einzelnen Users. Vor allem ist das Finden aller Sessions eines Users gar nicht so leicht, die sind ja über ihre Session-ID geschlüsselt und typischerweise irgendwie codiert gespeichert. Das ist aufwändig zu implementieren.

Aber der Konsens scheint ja zu sein: Das ist nicht so gravierend.

Rolf

[Felix Riesterer]

Lieber Rolf,

Felix' Idee einer Wahlmöglichkeit gefällt mir da eher weniger. Ob man Sessions nach Passwortänderung invalidiert, ist das Ergebnis eines Security-Assessments der betreffenden Site, keine Entscheidung des einzelnen Users.

und damit argumentierst Du - egal ob absichtlich oder nicht - in derselben Richtung wie das BSI, welches es einst auch als sicherer befand, wenn User dazu gezwungen werden, regelmäßig ihre Passwörter zu ändern. Userbevormundung ist nicht immer besser, auch nicht bei Fragen der Sicherheit!

Was ein User tun darf oder nicht, regelt ein Rechtemanagement. Was ein gehackter Account darf, unterliegt damit auch diesem Rechtemanagement. Da hilft auch nicht, wenn eine Passwortänderung automatisch alle Sessions zerstört!

Wenn ein User sein Passwort ändern will, weil er meint, dass sein Account gehackt wurde, mag er vielleicht genau deshalb alle Sessions damit killen. Wenn das dann nicht möglich ist (siehe Windoof-Sessions), dann ist das zum Nachteil des Users. Und wenn er nur sein Passwort vergessen hat und den Reset-Mechanismus bemüht, dann will er sehr wahrscheinlich nicht, dass er auf allen anderen Geräten aus seinen dortigen Sessions geworfen wird. Sollte das System das aber erzwingen, ist das eben Mist!

Vor allem ist das Finden aller Sessions eines Users gar nicht so leicht, die sind ja über ihre Session-ID geschlüsselt und typischerweise irgendwie codiert gespeichert. Das ist aufwändig zu implementieren.

Das verstehe ich nicht. Redest Du von einem best practice-Beispiel, oder von unserem Wiki oder Forum? In meinem aktuellen Projekt gibt es in der Session-Tabelle neben dem Primärschlüssel (Session-Token) auch einen Schlüssel für den damit angemeldeten User (Benutzername). Warum auch nicht? Was ein angemeldeter User darf, regelt das Rechtemanagement. Und wenn ich den Admin-Account nutze, muss ich eben darauf achten, dass ich mich brav wieder abmelde, ehe ich den Browser schließe.

Hier im Forum bleibe ich angemeldet. Wer meine Session klaut, hat damit potenziell die Möglichkeit Admin-Funktionalitäten zu nutzen. Das benötigt zwar eintsprechende Klicks, aber keine erneute Passworteingabe. Man könnte darüber nachdenken, ob für solche Anfragen gesondert geprüft wird, wann das letzte Mal ein Passwort eingegeben wurde, um im Bedarfsfall erneut dazu aufzufordern. Also im Grunde ähnlich der Verwendung von sudo auf einer Shell, wo auch ein Timer prüft, ob Du Dein root-Passwort erneut eingeben musst.

Liebe Grüße

Felix Riesterer

[Auge]

Hallo

Ich verstehe nicht, worauf du mit deiner Vermischung von „Benutzer ändert Passwort, bleibt aber mit einer Session, die mit dem alten Passwort gestartet wurde, eingeloggt“ und „Benutzer muss regelmäßig sein Passwort ändern“ hinaus willst. Das eine hat mit dem anderen im Kontext dieses Threads nichts zu tun.

Felix' Idee einer Wahlmöglichkeit gefällt mir da eher weniger. Ob man Sessions nach Passwortänderung invalidiert, ist das Ergebnis eines Security-Assessments der betreffenden Site, keine Entscheidung des einzelnen Users.

und damit argumentierst Du - egal ob absichtlich oder nicht - in derselben Richtung wie das BSI, welches es einst auch als sicherer befand, wenn User dazu gezwungen werden, regelmäßig ihre Passwörter zu ändern. Userbevormundung ist nicht immer besser, auch nicht bei Fragen der Sicherheit!

Hier geht es aber nicht darum, dass der Benutzer vom System gezwungen wird, regelmäßig sein Passwort zu ändern, sondern darum, dass er das – aus welchen Gründen auch immer – (mutmaßlich einmalig) getan hat. Das Passwort wurde geändert und es geht darum, was daraus in Hinsicht auf bestehende Sessions folgen soll und ob es ein relevanter Bug ist, die vor der Passwortänderung erzeugten Sessions, die mit einer so nicht mehr existierenden Anmeldung erzeugt wurden, weiterbestehen zu lassen.

Was ein User tun darf oder nicht, regelt ein Rechtemanagement. Was ein gehackter Account darf, unterliegt damit auch diesem Rechtemanagement. Da hilft auch nicht, wenn eine Passwortänderung automatisch alle Sessions zerstört!

Das ist soweit korrekt. Aber auch darum geht es nicht, denn was der konkrete Benutzer tun darf und was nicht, steht ja, qua seiner vorhandenen Berechtigungen, bereits fest. Die Frage hier ist ja, ob bereits bestehende Sessions nach der Passwortänderung invalidiert werden sollen. Einerseits kann mit der Invalidierung der Sessions einem potentiell existierender Angreifer, der eine solche Session gekapert hat, verunmöglicht werden, diese Berechtigungen selbst zu nutzen, andererseits nötigt es dem eigentlichen Benutzer ab, sich auf allen Geräten erneut einzuloggen.

In Kürze also: Ist der mögliche Angriffsvektor so groß, dass es nötig erscheint, die vorhandenen Anmeldungen nach einer Passwortänderung zu killen und den Benutzer mit der Aufgabe, sich überall neu einzuloggen, aus seiner Bequemlichkeit zu holen?

Wenn ein User sein Passwort ändern will, weil er meint, dass sein Account gehackt wurde, mag er vielleicht genau deshalb alle Sessions damit killen.

Ich halte das prinzipiell für den richtigen, konsequenten Weg. Nicht nur bei Hackverdacht, sondern jedesmal, wenn ein neues Passwort festgelegt wird. Das passiert ja üblicherweise nicht aus Jux und Dallerei. Allerdings lasse ich bei „prinzipiell“ die mögliche Schwere der Bedrohung außen vor. Wenn ein Angreifer im Wiki mit einer gekaperten Anmeldung eines einfachen Benutzers Spam hinterlässt, ist das ärgerlich, aber mit etwas Arbeitsaufwand behebbar ^[1]. Wenn die gekaperte Session einem Benutzer mit erweiterten Berechtigungen gehört, kann das schnell gehörig in die Hose gehen (dazu ganz unten noch ein paar Worte).

Und wenn er nur sein Passwort vergessen hat und den Reset-Mechanismus bemüht, dann will er sehr wahrscheinlich nicht, dass er auf allen anderen Geräten aus seinen dortigen Sessions geworfen wird. Sollte das System das aber erzwingen, ist das eben Mist!

Warum sollte er das nicht wollen? Wenn ich für ein System, auf das ich von mehreren Geräten aus zugreife, ein neues Passwort festlege, erwarte ^[2] ich, mich mit diesem neuen Passwort überall erneut einloggen zu müssen. Mir fällt auf die Schnelle nicht einmal ein System ein, bei dem das gewollt anders wäre.

Hier im Forum bleibe ich angemeldet. Wer meine Session klaut, hat damit potenziell die Möglichkeit Admin-Funktionalitäten zu nutzen. Das benötigt zwar eintsprechende Klicks, aber keine erneute Passworteingabe. Man könnte darüber nachdenken, ob für solche Anfragen gesondert geprüft wird, wann das letzte Mal ein Passwort eingegeben wurde, um im Bedarfsfall erneut dazu aufzufordern.

Ist es wirklich sinnvoll, eine solche Extrawurst für bestimmte Berechtigungsgruppen zu braten? Für die Ausführung von bestimmten Aufgaben kann ich mir das noch vorstellen. In der NextCloud-Weboberfläche muss man als Admin, wenn man eine gewissen Anzahl an Minuten eingeloggt war, ohne eine Aktion auszuführen, sein Passwort eingeben, um dies oder das zu tun. Man könnte also die Ausführung bestimmter Aktionen an eine erneute Eingabe des Passworts binden. Wenn ein potentieller Angreifer aber das benötigte Passwort hat, wird damit aber auch nichts abgesichert.

Ich halte es hingegen nicht für sinnvoll, für „normale“ Benutzer eines Systems die Bequemlichkeit des angemeldet bleibens bereitzustellen aber genau jenen, die das System am Laufen halten, diese Bequemlichkeit per se vorzuenthalten ^[3]. Bliebe also eine zum im vorherigen Absatz beschriebenen Ansatz von NextCLoud vergleichbare Funktion. Aber eben mit der Einschränkung, dass das gegen einen Angriff mit bekanntem Passwort nicht hilft.

Mit dem ursprünglich diskutierten Problem, was mit vor einer Passwortänderung erzeugten Sessions eines Benutzers passieren soll, hat das, wie auch eine von dir ins Spiel gebrachte erzwungene regelmäßige Passwortänderung, aber nichts mehr zu tun. Entweder man hält das Angriffsrisiko für hoch genug oder die Logik, eine, mit einem nicht mehr gültigen Passwort erfolgte, Anmeldung/Session aufrechtzuerhalten, für falsch, dann muss man die Anmeldungen killen und einen neuen Login erzwingen, oder eben nicht. Ich bin für den Zwang einer erneuten Anmeldung ^[4], glaube aber in Bezug auf die Wiki-Software (und damit fing der Thread ja an) nicht, dass hier irgendwer die Kapazitäten hat, das softwareseitig zu lösen. Falls doch, sollte das auch an Wikimedia übermittelt werden, damit das für alle Betreiber der Software bereitgestellt werden kann.

Tschö, Auge

---

1. Ich habe als Moderator eines Forums auch schon einmal erlebt, dass ein Benutzer, der akut einen Spam-Eintrag nach dem anderen erzeugte, trotz einer nach wenigen Minuten erfolgten Sperre noch in der nächsten halben Stunde munter weitere hunderte Spam-Einträge erzeugte, weil eben seine Session weiterbestand. Und aufgehört hatte es wohl auch nur, weil er die Seite verließ und sich anderen Zielen zuwandte. Das hatte sich dann mit „etwas Arbeitsaufwand“. ↩︎

2. „Erwarten“ im Sinne von „ich gehe davon aus, dass das so ist“, nicht von „das ist mein expliziter Wunsch“, ↩︎

3. Im Sinne von „weil du erweiterte Berechtigungen hat, wollen wir aus Sicherheitsgründen von dir, dass du dich jedesmal neu einloggst.“. Das nur, falls du darauf hinaus wolltest. Wenn nicht, ignoriere den Absatz. 😀 ↩︎

4. Ich nutze das Forum und das Wiki (aber primär das Forum) über eine Woche hinweg gesehen auf mindestens drei Geräten, wäre also von einer ezwungenen erneuten Anmeldung nach Passwortänderung auf mehreren Geräten auch selbst betroffen. ↩︎

[Felix Riesterer]

Liebes Auge,

ich bin es mittlerweile gewöhnt, dass man mich nicht immer versteht. Aber hier sollte der Vergleich nur zeigen, dass eine Bevormundung des Users grundsätzlich keine gute Idee, und in meinen Augen sogar ein dark pattern ist.

Du vermengst in Deinem Posting (so wie ich es gelesen habe) zwei grundsätzlich unterschiedliche Szenarien:

1. gekaperte Session (Passwort unbekannt)
2. gekaperter Account (Passwort bekannt)

Wenn Du nun Admin-Funktionalitäten in NextCloud beschreibst, die nach einer gewissen Zeit der Inaktivität die Eingabe des Passwortes erfordern, wird der erste Fall erfolgreich behindert. Übertrüge man das auf meine Sessions hier im Forum und im MediaWiki, wäre mehr Sicherheit gegeben.

Im zweiten Fall hilft nur eine Passwort-Änderung, damit die Sache zum ersten Fall wird: bestehende Session mit unbekanntem Passwort.

Trotzdem bleibe ich bei meinem Votum, dass ein automatisches Abmelden aller Sessions des Users bei einem Passwort-Wechsel eine Entscheidung des Users bleiben muss, und nicht des Systems, weil der Architekt des Systems unmöglich die Bedürnisse der User in Gänze voraussehen kann.

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

das Thema ist sogar noch größer, hier habe ich eine Diskussion dazu gefunden.

Allerdings diskutieren sie da auch über Autorisierungsverfahren, die wir hier nicht haben (JWT).

Interessant fand ich, dass man Session Tokens invalidieren sollte, wenn sich Benutzerrechte ändern - für den Fall, dass die effektiven Rechte im Sessionstate gespeichert sind.

Eine Entscheidungfreiheit des Benutzers wird dort auch vorgeschlagen. Aber nur von einem, die Empfehlung des OWASP ist eine andere. Ob man ihr folgt, ist natürlich nochmal was anderes, und ist eine Folgerung aus dem Security-Assessment des Seitenbetreibers, kein Wunsch der bevormundungsfeindlichen User.

Natürlich hast Du recht, wenn Du sagst, dass eine Zwangszerstörung aller alten Session-Tokens für den Benutzer unbequem ist. Aber wenn's um Bequemlichkeit geht, dann war die Einführung von Passworten schon der Kardinalfehler. Security ist immer eine Form von Bevormundung. Weil die meisten User faule Säcke sind, was Sicherheit angeht (guck unter die Tastatur oder in die Schreibtisch-Schublade…).

Anyroad - was das Wiki angeht, hängen wir am Fliegenfänger von Mediawiki. Im Forum hätten wir Entscheidungsspielraum. Im Moment spüre ich aber keinen Druck, den Status Quo zu ändern.

Rolf

[Auge]

Hallo

ich bin es mittlerweile gewöhnt, dass man mich nicht immer versteht. Aber hier sollte der Vergleich nur zeigen, dass eine Bevormundung des Users grundsätzlich keine gute Idee, und in meinen Augen sogar ein dark pattern ist.

Das ist deine Ansicht.

Meine ist, wenn ein Benutzer sein Passwort ändert, sind seine Sessions, die er vor der Änderung des Passworts gestartet hat, technisch gesehen ungültig. Sie wurden mit nicht mehr gültigen Anmeldedaten erzeugt. Diese Sessions daher zu invalidieren und einen neuen Login mit den nunmehr gültigen Anmeldedaten zu erzwingen, ist meiner Meinung nach keineswegs eine Bevormundung, geschweige denn ein dark pattern. Es ist eine technische Notwendigkeit, um die Gültigkeit der Anmeldung(en) sicherzustellen.

Du vermengst in Deinem Posting (so wie ich es gelesen habe) zwei grundsätzlich unterschiedliche Szenarien:

1. gekaperte Session (Passwort unbekannt)
2. gekaperter Account (Passwort bekannt)

Ich vermenge das nicht. Ich gehen auf die Konsequenzen ein, die weiterbestehende Sessions nach einer Passwortänderung haben können. In dieser Hinsicht ist es auch Wurscht, ob 1. oder 2. zutrifft. Gekapert ist gekapert und mit der Invalidierung bestehender Sessions würden sowohl Fall 1. (die vorhandene Sesion wird beendet) als auch Fall 2. (ein neuer Login mit einem dem Angreifer nunmehr unbekannten Passwort wird erzwungen) erschlagen. Wobei ich selbst (bewusst) nur auf den Fall 2. (das Passwort ist dem Angreifer bekannt) einging.

Trotzdem bleibe ich bei meinem Votum, dass ein automatisches Abmelden aller Sessions des Users bei einem Passwort-Wechsel eine Entscheidung des Users bleiben muss, und nicht des Systems, weil der Architekt des Systems unmöglich die Bedürnisse der User in Gänze voraussehen kann.

Ich bin absolut nicht der Meinung, dass es im hier diskutierten Szenario um die Bedürfnisse des Nutzers gehen sollte, ja, gehen kann. Es kann nicht sein, dass der Benutzer sein Passwort ändert (aus welchen Gründen auch immer, das spielt hier keine Rolle) und erwartet, dass seine Anmeldungen, die mit einem nicht mehr gültigen Passwort erfolgt sind, zu seiner Bequemlichkeit bestehen beiben. Hier hat die Sicherheit des Systems (meiner Meinung nach absoluten) Vorrang. Anmeldungen haben mit gültigen Anmeldedaten zu erfolgen, das ist keine Bevormundung. Jemanden, der versucht, sich mit einem per se falschen Passwort anzumelden, würde man ja auch zurückweisen.

Jemanden, der an der Tür zu einem beschränkten Bereich sagt „Früher lautete das Passwort ‚Knickknack‘.“ lässt man ja auch nicht rein. Da fordert man doch auch das aktuelle Passwort ein oder weist den Einlass begehrenden ab, oder?

Tschö, Auge

[Felix Riesterer]

Liebes Auge,

und erwartet, dass seine Anmeldungen, die mit einem nicht mehr gültigen Passwort erfolgt sind, zu seiner Bequemlichkeit bestehen beiben.

das bedeutet, dass bei Deinen Szenarien die Sessions das jeweilige Passwort kennen, mit dem sie gestartet wurden. Wenn dem so ist, kann ja jede Session jederzeit prüfen, ob ihr Passwort noch gilt und daraufhin entsprechend reagieren. Das bedeutet aber, dass die Sessions das Passwort irgendwo im Klartext für sich speichern. Das wiederum wirft andere Fragen auf.

Liebe Grüße

Felix Riesterer

[MudGuard]

Hi,

das bedeutet, dass bei Deinen Szenarien die Sessions das jeweilige Passwort kennen, mit dem sie gestartet wurden. Wenn dem so ist, kann ja jede Session jederzeit prüfen, ob ihr Passwort noch gilt und daraufhin entsprechend reagieren.

Im Grunde müßte bei jedem Abruf vom Server jeweils geprüft werden, ob sich irgendwas an den Userdaten des Session-Users geändert hat - damit wäre dann auch der Fall abgedeckt, daß ein Admin dem User irgendwelche Rechte entzieht (ggf. sogar den User komplett löscht).

cu,
Andreas a/k/a MudGuard

[Auge]

Hallo

und erwartet, dass seine Anmeldungen, die mit einem nicht mehr gültigen Passwort erfolgt sind, zu seiner Bequemlichkeit bestehen beiben.

das bedeutet, dass bei Deinen Szenarien die Sessions das jeweilige Passwort kennen, mit dem sie gestartet wurden.

Nein, das Passwort kennen die Sessions natürlich nicht. Sollen und dürfen sie auch nicht. Aber das System weiß von der Passwortänderung und soll die Sessions, die vor dieser Änderung und damit mit einem alten Passwort gestartet wurden, schlicht killen und einen neuen Login mit den aktuellen Zugangsdaten einfordern.

Tschö, Auge

[Rolf B]

Lieber Felix,

Das bedeutet aber, dass die Sessions das Passwort irgendwo im Klartext für sich speichern.

Soll ich jetzt glauben, dass dir das als einzige Möglichkeit vorkam? Da würde mich erschrecken.

Rolf

[Raketenwilli]

Vor allem ist das Finden aller Sessions eines Users gar nicht so leicht, die sind ja über ihre Session-ID geschlüsselt

Hm. Im Falle einer Session-Datei kann man z.B. greppen - das geht überraschend schnell (Beispiel)

root@mini:~# time sessFiles=$(grep -Rn ':"adm";' /foo/sessions/* | cut -d ':' -f1)

real	0m0,007s
user	0m0,007s
sys	0m0,003s
root@mini:~# echo $sessFiles 
/foo/sessions/sess_92g9osrebbrbehu8c814t7l58b 
/foo/sessions/sess_rifjrn9i01talq4s2qfigmn9s8 
/foo/sessions/sess_t31l584r7ftcogpvnj6gkef91q
root@mini:~# rm -f $sessFiles;

(Pfade sind angepasst, Zeiten nicht) Ich weiß ja nicht, was das media-wiki macht und wie viele tausend Dateien auf dem Server durchsucht werden müssten.

Ist es ein Datenbankeintrag sollte das Löschen noch schneller gehen.