2021-12-21T23:42:00 styx-ccUnd wenn der Verdacht falsch war und der Hacker statt des Post-Its deine aktuelle Session gekapert hat?
2021-12-21T23:42:00 styx-ccIch würde zumindest auch die aktuelle Session durch eine neue ersetzen und an den ändernden Clienten aushändigen - dazu brauchts ja keine Nutzerinteraktion, denn der Client hat ja gerade das Passwort geändert und sich damit authentifiziert.
2021-12-21T23:42:00 styx-ccAnlehnend an:
https://security.stackexchange.com/questions/10512... (insbes. OWASP)
QuoteDas ist ein etwas anderes Szenario: Wenn aktuelle Sessions gekapert werden können, muss der Hacker gar kein Passwort eingeben. Da hilft nur ein Logout und danach Beheben der Ursache.
2021-12-22T08:35:36 styx-ccIch hatte da eher im Kopf, der Benutzer bemerkt in seinem Account Veränderungen die er nicht getätigt hat (Versuch der Änderung der Bankverbindung z.B.) und wird nervös, versucht zügig das Passwort zu wechseln - und genau hier ist imho eine neue Session angberacht, andernfalls hat der Benutzer ein neues Passwort und trotzdem nichts gewonnen.
2021-12-22T08:35:36 styx-ccOb nun "automagisch" weil vorher schon eingebaut oder explizit, hauptsache die Session ist auf anderen Geräten ab sofort ungültig - oder habe ich einen denkfehler?
QuoteAber wenn Du davon ausgehst, dass Deine laufende Session gekapert wurde, dann solltest Du in keinem Fall in einer gekaperten Session das Passwort ändern. Das neue Passwort hat der Hacker damit auch gleich.
2021-12-22T12:17:50 styx-ccWas sprich dann dagegen das Passwort in dieser Session zu ändern und im Nachhinein die Session ungültig zu machen und neu zu vergeben?
2021-12-22T17:47:16 styx-ccIch schätze deine Beiträge ja sehr, aber heute geh ich mit dir nicht d'accord.
KonfuziusBe in harmony, yet be different.