Skip to content


Subversion checkout URL

You can clone with
Download ZIP


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

jmaxxz opened this Issue · 6 comments

5 participants


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.)


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?


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, :+1: 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.

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.