"Ruby on Rails 3 Tutorial" says,
"Ruby on Rails 3 Tutorial" says,
Which ruby on rails tutorial ? There are many ...
== This session object makes the user id available from page to page by storing it in a cookie that expires upon browser close... Because of the way Rails handles sessions this process is secure; if a malicious user tries to spoof the user id, Rails will detect a mismatch based on a special session id generated for each session.
Okay, so the spoofer can guess a user id, e.g. 1, and create a cookie with that id, but when he logs into the app, rails will give the spoofer his own session id, and the [spoofer_session_id, user_id] will not be a pairing that Rails allows.
Another important thing is that the data in the session store is cryptographically signed - if you tamper with the cookie data then it won't match the signature in the coookie
Whoa. What happens in this scenario: user logs in and rails stores a permanent, impossible to guess token with a timestamp in a cookie on the user's computer. The user goes on vacation for two weeks. While the user is on vacation, the malicious user gains access to the user's computer and inspects the cookies on the user's computer, and copies the token plus timestamp. The malicious user goes to his computer, creates a cookie with the copied token, and logs into the app. Won't the malicious user have free access to the user's account? When the malicious user logs out of the user's account, won't rails store a token with a timestamp on the malicious user's computer? In fact won't the real user find it impossible to access his account when he gets back from vacation because his timestamp will no longer be valid?
Again guessing because I don't know which tutorial you are talking about, but I believe the pattern being discussed is one where whenever the user logs in then the permanent token is replaced (and so any old/ previously stolen tokens stop working). So you can still steal browser cookies but they will only be useful until the user next logs in. If the user's token is invalid then they can sign in using their username and password.
Fred
Frederick Cheung wrote in post #1013777:
"Ruby on Rails 3 Tutorial" says,
Which ruby on rails tutorial ? There are many ...
It's the name of a book, which I think is fairly famous, and it happens to be available online at the author's website:
http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller
but I've quoted the relevant parts.
his own session id, and the [spoofer_session_id, user_id] will not be a pairing that Rails allows.
Another important thing is that the data in the session store is cryptographically signed - if you tamper with the cookie data then it won't match the signature in the coookie
I don't see how that is relevant. It doesn't matter what's in a cookie if someone copies the cookie. Cryptographically altering the id 1, just makes it hard to guess the cookie. But in my scenario, the malicious user copies the cookie, so it doesn't matter if the cookie data is 'red' or 'XADFASDFASDFSADFASDFASDFASDF521374129348712398".
the malicious user logs out of the user's account, won't rails store a token with a timestamp on the malicious user's computer? In fact won't the real user find it impossible to access his account when he gets back from vacation because his timestamp will no longer be valid?
Again guessing because I don't know which tutorial you are talking about, but I believe the pattern being discussed is one where whenever the user logs in then the permanent token is replaced (and so any old/ previously stolen tokens stop working). So you can still steal browser cookies but they will only be useful until the user next logs in. If the user's token is invalid then they can sign in using their username and password.
Ah, I see. So the malicious user will have access to the account until the user returns from vacation. Then when the user visits the website, rails won't recognize him as a signed in user--but the user can still sign in with his name and password to gain access to the account. Subsequently, the malicious user's cookie won't work because of an invalid timestamp, and he won't be able to access the account anymore. However, what prevents the malicious user from changing the password, and permanently hijacking the account?
Frederick Cheung wrote in post #1013777:
> Another important thing is that the data in the session store is > cryptographically signed - if you tamper with the cookie data then it > won't match the signature in the coookie
I don't see how that is relevant. It doesn't matter what's in a cookie if someone copies the cookie. Cryptographically altering the id 1, just makes it hard to guess the cookie. But in my scenario, the malicious user copies the cookie, so it doesn't matter if the cookie data is 'red' or 'XADFASDFASDFSADFASDFASDFASDF521374129348712398".
Just above you wrote (or quoted) "Okay, so the spoofer can guess a user id, e.g. 1, and create a cookie with that id, " and I'm saying that you can't spoof tails session cookies like that.
> Again guessing because I don't know which tutorial you are talking > about, but I believe the pattern being discussed is one where whenever > the user logs in then the permanent token is replaced (and so any old/ > previously stolen tokens stop working). So you can still steal browser > cookies but they will only be useful until the user next logs in. If > the user's token is invalid then they can sign in using their username > and password.
Ah, I see. So the malicious user will have access to the account until the user returns from vacation. Then when the user visits the website, rails won't recognize him as a signed in user--but the user can still sign in with his name and password to gain access to the account. Subsequently, the malicious user's cookie won't work because of an invalid timestamp, and he won't be able to access the account anymore. However, what prevents the malicious user from changing the password, and permanently hijacking the account?
Most websites require you to supply the existing password to change a password.
Fred
Okay, so the malicious user still has two weeks of access to the account for his troubles, right?
The only way we have determined that this is possible is with physical access to the computer. As in any security scheme, that pretty well trumps anything that doesn't rely on the user logging in every time, and time-limited sessions.
As with any form of security, it's not a matter of absolutes, but rather a balancing act between user discomfort and reasonable protection. Nothing is foolproof, and the real problem is the user in any case.
Walter
Walter Davis wrote in post #1013792:
The only way we have determined that this is possible is with physical access to the computer.
Are you saying that the malicious user can only gain access to the user's account while using the user's computer? Or, is it true that once the malicious user has a copy of the cookie, he can access the account from any computer?
As in any security scheme, that pretty well trumps anything that doesn't rely on the user logging in every time, and time-limited sessions.
I wasn't critiquing rails, I was trying to understand why the author of the book said the persistent session was impervious to attack--after himself raising the specter of a malicious user gaining access to the user's computer. His explanation didn't make sense to me.
Walter Davis wrote in post #1013792:
The only way we have determined that this is possible is with physical access to the computer.
Are you saying that the malicious user can only gain access to the user's account while using the user's computer? Or, is it true that once the malicious user has a copy of the cookie, he can access the account from any computer?
As in any security scheme, that pretty well trumps anything that doesn't rely on the user logging in every time, and time-limited sessions.
I wasn't critiquing rails, I was trying to understand why the author of the book said the persistent session was impervious to attack--after himself raising the specter of a malicious user gaining access to the user's computer. His explanation didn't make sense to me.
In answer to both of your questions, I was saying that physical access to a computer where the user has checked the "remember me" option completely trumps the security system. The computer becomes the key to the lock, so if you steal that key... Which is another good reason to always include a password lock on your screensaver, and disable any auto-login convenience features. Especially on a laptop, but even on a desktop that isn't in a locked room.
As far as a copy of the cookie being useful, I'm not sure I can comment. I think that it would work up until the point where the real user logged in again, and the fact that the user *had* to log in again might worry/alert a suitably clueful user that their remember me cookie had changed. But I can't say definitively, because I don't know what all goes into the cryptographic signature of the remember me cookie. If it's something based on the individual browser, then it seems likely to me that it might fail on a different browser.
Walter
Walter Davis wrote in post #1013792:
> The only way we have determined that this is possible is with physical > access to the computer.
Are you saying that the malicious user can only gain access to the user's account while using the user's computer? Or, is it true that once the malicious user has a copy of the cookie, he can access the account from any computer?
In the scheme you've outlined, I think it would work from any computer. It could be extended though. I once implemented a scheme whereby the ip address was part of the cryptographically signed info so that the persistent cookie was valid only from that ip address (obviously this has some limitations/problems too)
Frdd
Sure, but at this point the user is pretty throughly pwned anyways - there's no system that will protect the login here, short of ditching the whole "persistent login" part and requiring the user to re- autheticate on each visit.
--Matt Jones
