On Tue, Oct 2, 2012 at 5:23 PM, Tom Evans <tevans...@googlemail.com> wrote:
> 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. That sure is a loaded comment, let's keep the dick size wars out of this yeah? :) > 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? Let's see.. Facebook? --snip-- "Log out of other devices? To make sure your account's secure, we can log you out of any other computers and phones. You can log back in with your new password." --snip The only difference is that Facebook make it an optional feature that pops up immediately after you change the password. The expectation comes from a simple logic. If I change my password, I want to think that my account is secure from anyone else that previously had it. > 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? > That's a different question entirely, and comes down to a business logic choice, not a technical "one-fits-all". > > 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. The solution I specified was the most simple approach possible, and could be integrated without too much fuss. If you wanted more control, then yes tracking and invalidating individual sessions against your authentication model is the way forward. > > 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.
