Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

user_credential cookie vulnerable to replay attack after user logs out #309

Open
jmaxxz opened this Issue Apr 15, 2012 · 10 comments

Comments

Projects
None yet
6 participants

jmaxxz commented Apr 15, 2012

user_credential cookie is the same every-time a user logs in. System should generate a new random user_credential every time user logs in. When a user logs out this session credential should be invalidated. This is a risk because under the current implementation if a user's user_credential is ever compromised it remains usable as a credential long after the user has logged out.

Consider tracking user session credentials and expiration in a separate table, this way the persistence token for each user session can b randomly generated at every login, expired after a specified time, and disabled by user. (think of gmail's log me out from all other locations feature.)

maletor commented Jul 1, 2012

Any updates on this?

Why wouldn't a link between session and user be stored in the server? I was under the assumption the logged in user was associated with a session. I spent hours trying to find the association in my database until I looked at the cookie and saw that user identification and user session are independently in the cookie.

From what I can tell, there is no way from the server side to know which session is associated with which user. This is important for banning users, where you might want to immediately invalidate their session. In order to invalidate a session in this way, you need to know all sessions associated with one user.

@jmaxxz wondering, as it's been 3 years.. you ever found a way to overcome this?

Collaborator

tiegz commented Mar 9, 2015

Some thoughts:

  • session hijacking can be mitigated/avoided through HTTPOnly/SSL cookies and HTTPS connections.
  • if you want to be more aggressive about this you could call reset_persistence_token in an after_destroy callback on your session model.
  • if you want to do the latter but also allow unique logins for the same user from multiple computers, 👍 for a PR to setup multiple persistence_tokens. Authlogic doesn't have migration generators tho, so this might be a good reason to add them.

jmaxxz commented Mar 9, 2015

@AvnerCohen use JWT tokens instead of this project. It has been a while since I have done RoR work so I don't feel I can provide you good advice on a lib to do that.

@jmaxxz thanks :) I'm way after the call on what project to use. JWT where I can, but this is some legacy I can't easily drop.

@tiegz thanks for your input. reset_persistence_token is not a really a solution I could use. If I do that, A user will be kicked off from all his session (consider a web and mobile session), which is not a reasonable UX.

Yeah, multiple persistence_tokens seems to be a reasonable solution. I'll check to see if this something we require.

@AvnerCohen you ever find a good solution to this? Same boat, legacy code :/

@grantgeorge Nope, never found one.

From security stand point, the only thing one can say is that if an attacker got your login cookie (and SSL is assumed), he is probably on your machine already, so maybe this is the least of your concerns...
But yeah, that's still an issue..

@AvnerCohen dang, thanks man. As far as I can tell Authlogic uses this user_credentials cookie to determine if a session exists. It makes no sense to me why it can't just depend on session

Collaborator

tiegz commented Mar 22, 2016

@grantgeorge authlogic tries both cookie and session. OTOH I think you may be able to set remember_me_for to 0 to skip that cookie?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment