"Ruby on Rails 3 Tutorial" says, =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. =For our application''s design choice, which involves persistent sessions--that is, signin status that lasts even after browser close--storing the user id is a security hole. As soon as we break the tie between the special session id and stored user id, a malicious user could [basically guess an id, e.g. 1, and create a cookie with that id and sign in.] = Okay, so in this case Rails wouldn''t be able to spot the spoofer because the real user won''t have a session id either when he logs in again. =To fix this flaw, we generate a unique, secure token [instead of using the user''s id] based on the user''s salt and id. = Okay, that just prevents the spoofer from easily guessing a user id: for instance guessing 1 won''t work anymore. =Moreover, a [permanent token] would also represent a security hole--by inspecting the browser cookies, a malicious user could find the token and then use it to sign in from any other computer, any time. We solve this by adding a timestamp to the token, and reset the token every time the user signs into the application. This results in a persistent session essentially impervious to attack. = 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? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jul 29, 3:49 pm, 7stud -- <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> "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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Frederick Cheung wrote in post #1013777:> On Jul 29, 3:49pm, 7stud -- <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: >> "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? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jul 29, 5:41 pm, 7stud -- <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> 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> > -- > Posted viahttp://www.ruby-forum.com/.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Okay, so the malicious user still has two weeks of access to the account for his troubles, right? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 On Jul 29, 2011, at 1:46 PM, 7stud -- wrote:> Okay, so the malicious user still has two weeks of access to the > account > for his troubles, right? > > -- > Posted via http://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails- > talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > . > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en > . >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jul 29, 2011, at 3:07 PM, 7stud -- wrote:> 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> > -- > Posted via http://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails- > talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > . > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en > . >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jul 29, 8:07 pm, 7stud -- <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> 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> > 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. > > -- > Posted viahttp://www.ruby-forum.com/.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jul 29, 10:49 am, 7stud -- <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> 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?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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.