sessions and security?

"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