Consider a case, where an attacker has physical access of user's machine for 20-30 seconds.
The attacker can use this time to steal user's cookie (say using EditThisCookie plugin) and send the cookies to himself (say by hangouts, facebook, mail, etc).

The account of the user is compromised forever.
I have tried out the experiment myself, where say XYZ's-cookie "X" is stolen from my system. After which I change the password of my XYZ account. Still the attacker can access my account by using cookie "X".
Also, sometimes it has happened with me that the cookies stolen ("X") when inserted in the browser doesn't work. I want to know why this weird behavior happens and what kind of state is stored in cookies. I have read about the expiry date to be stored in the cookie, but generally it's stored 1 year or so from the current date (am not sure about this fact though).

I also wanted to know if there's any method in current web architecture to prevent the click-jacking attack where cookies are physically stolen (as described above).

  • i remember i had done the same with facebook..but couldnt log from another account Jun 1, 2016 at 12:36

2 Answers 2


The cookies are there to avoid authenticating via a password for each web transaction (otherwise each protected page would need to be reauthenticated every time it is accessed).

In that sense cookies are independent of the password.

They should be checked by

  • the browser which verifies that their validity has not expired. The server should never rely on this check for security means as the browser is controlled by the client (and can elect not to check the validity)
  • the server which ensures that the cookie it retrieves from the client is still valid according to its (the server's) own criteria (it should keep track of the validity of the cookies independently of a possible "validity time" within the cookie).

Therefore the fact that you changed the password does not necessarily mean that the cookie is invalid. It should be the case because the server should invalidate them on his side.
Logging out is the normal way (or rather - should be) to invalidate sessions.

There is not much more beyond that (in terms of cookies as an authentication mechanism) - they are one possible way to avoid constant reauthentication.


To add to what @WoJ said, this behaviour is not ideal, but larger sites often provide a list of active sessions, which usually includes the accessing IP address, and gives the option of expiring specific sessions. In the case of multiple IP address simultaneously accessing the site using the same session details (the same cookie, in this case), I would expect a secure system to expire that session and log both instances out, prompting for the user to log in again.

In general, expiring all active sessions is best practice when a password is changed on an account, but there are cases where this is not done. Furthermore, even when this is not (maybe the site doesn't want to log users out of mobile sessions for some reason), the current session identifier should be changed - this would normally be indicated to the browser by setting a new cookie.

There is a related vulnerability known as session-fixation, where a specified cookie is not changed upon login, so an attacker who has been able to set a cookie in advance (presumably through access to the machine) can force the site to use a known session identifier, which would have the same result - an attacker being able to use the same session as the legitimate user. Again, the fix is to ensure that upon login, the session identifier is regenerated.

Incidentally, neither of these are click-jacking - that's a distinct attack.

  • i had tried this fb earlier but couldnt succeed..are you saying that fb must have been doing the same thing as u said..it would be tracking the ip address as well and if it checks that the same cookie is being used by another ip address, it will block me out Jun 1, 2016 at 12:39

You must log in to answer this question.

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