Sorry, my previous reply looked like I was disagreeing with the OP, this is not the case.
I was disagreeing with this comment; Sessions aren't tied to specific users, and so cannot easily be invalidated like that. Personally, I wouldn't have the expectation that changing my password would invalidate all my other sessions, but perhaps a lay user would. Google Mail in-line reply seems to be a bit fudged the last few days... :X Cal On Tue, Oct 2, 2012 at 4:43 PM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > > > On Tue, Oct 2, 2012 at 3:51 PM, Tom Evans <tevans...@googlemail.com>wrote: > >> On Tue, Oct 2, 2012 at 3:22 PM, Dirley <dirley...@gmail.com> wrote: >> > I've recently discovered this issue with my django based application. >> > >> > When a users changes its password, its active sessions are not >> destroyed. >> > I mean, if a user is logged in two different places (or in two different >> > browsers) and changes its password on one place, the other session will >> still >> > be active. >> > > Actually, I disagree with this. > > Say for example a user changes their password due to a security breach on > their account.. if the session is not invalidated, the other user could > carry on having access to their account for the maximum duration that the > session allows. > > The way we implemented this for one of our clients, was to cache the user > password hash in the session, and re-check it against the database every X > seconds. If it is different, the session is logged out. > > The user which then triggers the password change will automatically have > the cached session password hash updated, and thus the original session > does not get terminated. > > >> > >> > I think this is an issue. If a user thinks his password has been stolen, >> > he'll naturally change his password in the hope that this action will >> revoke >> > the robber's undue access to his account. It's kinda "expected" that >> after a >> > password change, everyone with your old password will not be allowed to >> login. >> > >> > But as far as I can tell, this has been the default behaviour for a >> long time >> > and no one ever bothered. So, am I missing something? Maybe my specific >> > setup (I changed my auth backend a little bit) is problematic? >> > >> > - D >> > >> >> Sessions aren't tied to specific users, and so cannot easily be >> invalidated like that. Personally, I wouldn't have the expectation >> that changing my password would invalidate all my other sessions, but >> perhaps a lay user would. >> >> It is simple to add some middleware to ensure that sessions are linked >> to user objects, and then you can insert any business logic you need >> to take the appropriate action, eg to logout other sessions on a >> password change. >> >> Cheers >> >> Tom >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-users@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
