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 did not say that it was not a desired feature, I said that *personally* I would not have that expectation; this may be due to me fully understanding how such systems work and, as I indicated, a lay person may think differently. Other large commercial systems, for instance google apps, do not behave in this manner, so I'm not sure where the expectation comes from - can anyone name a public facing system that invalidates all other sessions on password change? As a corollary, remember that django's authentication contrib package, django.contrib.auth, is designed to be a *base* that all AAA schemes can be built around. There are many schemes where a user may have many passwords for a single account, should changing one of them invalidate all their other sessions? As I said in my original reply, these sorts of BI rules can trivially be added on top of d.c.auth. I gave one such mechanism, Cal another. Cal's solution is more about ensuring that only sessions that have the current valid password hash are allowed, whilst mine is more about tracking and invalidating specific sessions on a whim. 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.
