On Tue, Jan 10, 2012 at 4:18 PM, Arnoud van Heuvelen
wrote:
> I see your point. However, if a malicious user would change the password, at
> least the original user would be logged out and not be able to log in again.
> Now, that user knows something is going on and can notify a server admin who
>
Op dinsdag 10 januari 2012 03:56:04 UTC+1 schreef Sergiy het volgende:
>
> I'm not sure that invalidating session based on last password change is
> the right thing to do. If the password has been compromised, this
> effectively enables an active attacker to deny access to the legitimate
> user.
I'm not sure that invalidating session based on last password change is the
right thing to do. If the password has been compromised, this effectively
enables an active attacker to deny access to the legitimate user. In case
of Django admin site this can be quite disruptive as there is no password
r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/09/2012 09:01 AM, Carl Meyer wrote:
> This is not an option because the database session backend is only one
> of many session backends.
Oh, never mind - I misunderstood the proposal. This wouldn't be
dependent on using the database session back
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/2012 03:57 PM, Arnoud van Heuvelen wrote:
[snip]
> 2) Build a relation table that links the sessions to the users. (Or
> use a CSV in the user object.) This could be done completely in the
> auth package. Downside is that we have to create a n
Options 2 and 4 from that list both involve database-level changes, and
thus aren't feasible (our lack of schema migration tools being the biggest
problem).
Of those, I'd go for option 3 as well. We definitely don't want to store
the full hash in the session for obvious security reasons, but a
On Sun, Jan 8, 2012 at 2:57 PM, Arnoud van Heuvelen
wrote:
...
> 3) Save the password hash (or part of it) in the session and compare
> it against our data. If the hash is not the same, the user needs to be
> logged out. This wouldn't change the database, but the downside is
> that this causes ove
Well, as far as I see it, we have a number of options. These are some
I could come up with, but maybe someone else has a better idea:
1) Save the user_id with the session. This is probably not convenient,
because it might conflict with other applications that use the session
package. Of course we
And how could we do that? Sessions aren't linked to the user (well they
are, but not in a queryable way).
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/
Hi,
Yes. I agree with Arnoud. I have always felt a need to have such
a implementation with the default installation. I feel the auth system
should provide an in-built logout all sessions feature otherwise as
mentioned can comprimise heavily on the security if the developer doesnt
take car
Hi,
I recently ran into a minor security issue with Django Auth.
Currently, when a user changes their password, the user will stay
logged in on all open sessions.
This is a problem when a password is compromised. The user will change
their password and be confident that the problem is solved. How
11 matches
Mail list logo
