user_credential cookie vulnerable to replay attack after user logs out

[jmaxxz]

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]

Any updates on this?

[btbonval]

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.

[AvnerCohen]

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

[tiegz]

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]

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

[AvnerCohen]

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

[grantgeorge]

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

[AvnerCohen]

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

[grantgeorge]

@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

[tiegz]

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

[jaredbeck]

Hello, I'm going through old authlogic issues and seeing what to do with them.
This one looks a bit like a usage question and a bit like a feature suggestion.

If this is a feature suggestion, it's still relevant, and you are committed to
implementing it, please open a new issue and we can discuss your implementation
plan.

If this is a usage question, please ask it on stackoverflow. Unfortunately,
we just don't have enough volunteers to handle usage questions on github. Also,
please check the reference documentation. You might find something there
that's not in the readme.

Thanks!