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.

  • 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, 2013 at 18:16

2 Answers 2


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.

  • 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, 2013 at 18:31
  • 2
    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". Jul 24, 2013 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, 2013 at 10:08

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .