It's quite easy to record the last login time to deny cookie-based authentication after a given period. I suppose if someone else got the cookie, they could follow after the real user logged in... and it would work, since the user token doesn't change for each login as with standard sessions.
I ran across this site today... looks helpful: http://www.rorsecurity.info/
- nathan.
I always find with security people that they are good at talking about theoretical risks, but poor at providing evidence that the actual risk
is significant.
Can somebody show a security violation with correctly architectured Rails application (ID/Flash session)?
If you’re just storing an ID and the flash, then the only danger is
the rather infeasible one of someone cracking your secret by brute forcing the hmac.
The additional risk is that because cookie sessions can’t be expired, an attacker with access to your cookie will be able to replay that
login indefinitely. Unlike the server side stores where someone gaining access to your cookie only has access for as long as it takes for you to clear out the server side store.
If you can detect that it happened, you can invalidate all the cookies at once by changing the secret. If you can’t detect, then you’re open to another type of attack. Given the secret and lucky guessing of IDs, the attacker can end up masquarading as any user they choose to be. And most IDs are very easy to guess, if not from urls (/people/1) then just by assuming lower numbers are more likely to be admins.
Assaf
If you can detect that it happened, you can invalidate all the cookies at once by changing the secret. If you can't detect, then you're open to another type of attack. Given the secret and lucky guessing of IDs, the attacker can end up masquarading as any user they choose to be. And most IDs are very easy to guess, if not from urls (/people/1) then just by assuming lower numbers are more likely to be admins.
Absolutely, if you lose the secret, you're in trouble.
If you can detect that it happened, you can invalidate all the cookies at once by changing the secret. If you can’t detect, then you’re open to another type of attack. Given the secret and lucky guessing of IDs, the
attacker can end up masquarading as any user they choose to be. And most IDs are very easy to guess, if not from urls (/people/1) then just by assuming lower numbers are more likely to be admins.
Absolutely, if you lose the secret, you’re in trouble.
Indeed. But by analogy, you’re storing all the username/passwords in clear text under the config directory, and then placing a crypted copy of that same file in public. Just a matter of how confident you feel with that extra exposure of your secrets.
Assaf
Did I miss something obvious? - Many people have pointed out that the secret can be brute forced. If an attacker can forge the session data in arbitrary ways, then they can change their session's user ID to that of an admin and wreak havoc. - It becomes impossible to properly timeout a session without an admin manually changing the server. Cookie expiration dates is unreliable, not only because the client can ignore it but also because many computers have an incorrectly setup clock. I usually store the expiration date of a session inside that session, and check that expiration date in the server. But with the cookie store, that expiration date can now be forged. - Rails 1.2 session data cannot be forged arbitrarily because everything is stored on the server; the worst thing that can happen is that an attacker finds out what an admin's session ID is. But even then, if the session ID is too old then it can be expired by the server.
All of these risks are based on the assumption that it's feasible to brute force the secret. As far as I'm aware it's not. As we've said before, if someone wants to provide patches to implement public key encryption instead of HMACs, we'll take them.
I think there's still a lot of fear and misinformation floating around. I have written a summary of the whole situation, as well as my own view, at: http://izumi.plan99.net/blog/index.php/2007/11/25/rails-20-cookie-session-store-and-security/
- Many people have pointed out that the secret can be brute forced. If an attacker can forge the session data in arbitrary ways, then they can change their session's user ID to that of an admin and wreak havoc.
See http://izumi.plan99.net/blog/index.php/2007/11/25/rails-20-cookie-session-store-and-security/ for a rundown on why brute-forcing is not feasible.
- It becomes impossible to properly timeout a session without an admin manually changing the server. Cookie expiration dates is unreliable, not only because the client can ignore it but also because many computers have an incorrectly setup clock. I usually store the expiration date of a session inside that session, and check that expiration date in the server. But with the cookie store, that expiration date can now be forged.
Again, it cannot be forged. See link above for a rundown of why. So you can still store a expiration date in the session.
> - Many people have pointed out that the secret can be brute forced. If > an attacker can forge the session data in arbitrary ways, then they > can change their session's user ID to that of an admin and wreak > havoc.
Seehttp://izumi.plan99.net/blog/index.php/2007/11/25/rails-20-cookie-ses… for a rundown on why brute-forcing is not feasible.
I just learned about the high humor of me pointing you to your own blog :). That's priceless.
Indeed. 
However, I have changed my opinion. A comment as well as a
website turned a tide. Please read
http://izumi.plan99.net/blog/index.php/2007/11/26/rails-20-cookiestore-insecure-after-all-because/
I believe the default Rails secret key generator is insecure and
should be fixed.