Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Considering the scenario where a Gmail session/login cookie is hijacked or stolen and it is discovered my means of Gmail last account activity,will changing my password immediately void the cookie or can the attacker still use the same cookie to authenticate?

I am assuming that this is the same for other sites as well such as Yahoo,Facebook given the way they deal with login cookies.

Also,if I have two factor authentication enable,will that help if my login session/cookie is hijacked.

share|improve this question
1  
(1) Session cookies are temporary and most of the time, deleted within 24 hours. (2) As for your additional question... yes, two factor authentication would void that - as well as more impacting security issues. (3) Gmail supports HTTPS... use it! –  e-sushi Jul 24 '13 at 18:16
add comment

2 Answers

up vote 3 down vote accepted

It really depends on how the server is implemented; you cannot count on either behaviour. For some servers, changing the password will invalidate the cookies; for others it will not.

On a typical server, there is a database with a table of users, and another table maintains the mapping of cookie values to user identities. With such a setup, changing the password alters only the first table, and it would take some extra effort from the programmer to also prune out the cookie values from the second table, which map to that user. Programmers are allergic to effort so chances are that in such a site, changing the password does not invalidate the cookie.

But some other sites merge the two tables, so that each user has one active cookie value, in which case voiding it upon password change is quite easy (a few extra characters in the SQL statement); then there is a roughly 50% chance that the programmer thought about it and bothered to add the few extra characters to his SQL statement.

Of course, Gmail cannot be assumed to be really "typical". So anything goes. You might want to try it:

  1. Log in with your Web browser.
  2. Close your Web browser (the process, not just the window).
  3. With another, distinct browser (or from another computer), log in and change your password.
  4. Reopen the first Web browser. See if it is granted access without entering a password.

Then you will know.

share|improve this answer
    
Thanks for the excellent tip.Will try out and get back. –  Madusudanan Jul 24 '13 at 18:03
1  
Good answer +1 but I'd start with a definite "no, you can't count on this" and then move into implementations differ and the details. –  adric Jul 24 '13 at 18:31
1  
Good answer, but you're loosing me at "programmers are allergic to effort". I'm sure you're trying to be funny - but truth is, if a design isn't done well and the requirements aren't clear, than randomly adding a feature like this is scope creep and poor practice - not a sign of being "extra diligent". –  bethlakshmi Jul 24 '13 at 19:15
    
@bethlakshmi: feel free to read "designer" or "the guy in charge of making the code happen" in that place. That's often the same person anyway. –  Tom Leek Jul 25 '13 at 10:08
add comment

If this something you care about - test it.

Tom Leek's answer is dead on in that how the cookie, account and password connection are totally dependent on the nature of design. It's actually an incredibly bad security practice to put a password or a permutation of the password in the cookie - so there is always some server-side logical connection between the cookie and the account.

Ideally the security requirements are documented and the design is well thought out to balance risk with expense, processing requirements, and user interface desires. But that's not always ideal - session and cookie management often falls through the cracks between developers, designers, and security engineers.

It's also a part of the code that generally isn't published as public knowledge.

I can tell you from experience in using google accounts, that a password change on one system has generally provoked the need to reenter the new password on other systems hours later. Couldn't tell you if it was timeout or related to how the sessions are managed. Also, I have no reason to believe that what works one way today won't change tomorrow.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.