Let's take Steam/Google/FB/Microsoft/Twitter logins as examples.

All of them offer two step verification through SMS message. Let's say the hacker does not have access to my phone. But he has access to my computer at one point in time.

The hacker extracted my cookie from my browser (it's easy to do) and then put that cookie into his browser.

Theoretically he could just use it to login to the service without having to go through the two step verification process.

Is there any way to detect this kind of behavior or prevent this from happening?

Furthermore, for service providers using OAuth authentication provided by the ones mentioned above, is there anything they could do to detect such behavior?

  • 5
    Are you asking if you personally can do anything, or if the service can do anything? The cookie can be bound to an ip address, though that may frustrate mobile users. Commented Mar 26, 2018 at 15:51
  • 1
    @AndrolGenhald if the service can do anything. IP bound would definitely frustrate mobile users and I don't think any service provider that offers mobile app would do that
    – Steve
    Commented Mar 26, 2018 at 15:53
  • 11
    Ask for 2fa again for every important task.
    – Xavier59
    Commented Mar 26, 2018 at 15:53
  • 1
    A way to avoid that problem is to have a dedicated dongle or app that you log into and use that to automatically answer to a challenge on every page. There is still a problem with securing the internal "cookie" of the dongle or of the app that answers the challenge which can be compromised in case of temporary physical access (but it is a lot harder than getting a cookie, and wouldn't be that common in scrapping tools).
    – satibel
    Commented Mar 27, 2018 at 2:41

2 Answers 2


Matthew's answer is definitely the correct answer, but I thought I'd follow up with more details:

Cookie-based authentication has a big weakness - the cookie is all you need to authenticate. If someone is able to steal a user's cookie, there is nothing built into the cookie authentication process that let's the server know that shenanigans have happened. You use the example of an attacker having physical access to the computer, but that is a rare case to look out for. XSS vulnerabilities on sites with insecure cookies are a far more common way for cookies to get stolen. Also common: session fixation attacks, packet sniffing over insecure wireless networks for sites that don't use https, and various other forms of MITM attacks. To be clear, this isn't just an issue for cookie-based authentication. The underlying problem is that HTTP is a stateless protocol, which means that if you can replay a previous request completely, there is no way (baked into HTTP) for the server to know that you are not the same person.

So how do services make sure that the person they talk to are the person they actually want to talk to? The answer is not necessarily straight-forward. As Matthew mentions, you have to monitor your access credentials in other ways: IP address changes, browser changes, user agent changes, etc... In essence you keep track of meta data related to the devices you are talking to and take close attention to any suspicious changes.

As you note in a comment, even this isn't fool-proof. People can obviously fake user-agents. This could possibly be countered by using device fingerprinting techniques (Device fingerprinting & Mass Computer Surveillance) which an attacker has substantially less control over. IP Addresses aren't fixed, especially for mobile carriers, but as long as each device has it's own cookie, even this can potentially be tracked and accounted for. If a given cookie has been associated with the same IP address for 6 months and is suddenly showing up in another country, you probably have a problem. If a device frequently changes IP addresses (i.e. a phone) but now shows up with an IP address not associated with a mobile carrier or their usual geographic area, you probably have a problem. The other thing to keep in mind is that each device should have a unique cookie. Therefore, even if the IP address associated with a cookie normally changes, if you are now receiving requests from that cookie from two different IP addresses at the same time, you probably have a problem.

In the end, the simplest way to fix things if their appears to be something fishy going on is to simply invalidate all cookies (aka log the user out). The legitimate user is only slightly inconvenienced - they just have to log back in. The attacker though has lost all access and has to start over.

The take away

There should be a couple obvious takeaways from the above discussion:

  1. There is no definite answer. A sufficiently smart attacker has lots of ways to try to hide that he has stolen credentials, once they are stolen.
  2. A system that hasn't setup extensive security/monitoring around their login credentials will have no way to know that something is going on, and no way to react.
  3. There is no clear "Okay, you are secure now" point. There is a lot that a system can do to secure login credentials, but ultimately there are things not under the server's control that can allow credentials to be stolen. There are ways to detect stolen credentials, but they are not always easy or straight-forward and can take a lot of effort to setup, tune, and use. It is also possible to be overzealous and cause problems for legitimate users.

So how do the big guys minimize the potential damage done from people walking away with credentials? Short answer: Defense in depth. Secure access credentials at all layers of the application, monitor meta data from clients using access credentials, and if in doubt, log them out.

  • 1
    "The legitimate user is only slightly inconvenienced..." Maybe. On the other hand, maybe logging them out resulted in losing that awesome SO answer they just spent 2 hours on.
    – jpmc26
    Commented Mar 26, 2018 at 23:01
  • 3
    The legitimate user is only slightly inconvenienced -- I beg to differ. Security is always a balance between usability and safety. I've worked in environments where the security was so onerous that it was almost impossible to get work done. Commented Mar 27, 2018 at 3:32
  • 2
    @jpmc26: Poor example; Stack autosaves answers in progress. Of course not all sites do. Commented Mar 27, 2018 at 8:11
  • 1
    @jpmc26 It's always a balance act. Depending on the application, a log out may be inconvenient, but depending on the application a malicious user in your account may be much less convenient. For something like SO I doubt I would bother with half the security measures outlined in my post - there isn't anything "valuable" enough to be worth those layers. For a banking app though, absolutely, and it is much better to err on the side of security. Commented Mar 27, 2018 at 12:11
  • 1
    @RobertHarvey That being said, logout doesn't have to be the answer. In the case where you end up with the same auth token coming up from two different clients, there are often ways to tell which is the legitimate user, send new credentials to that user, and then cancel the old credentials, effectively logging out just the malicious user. That can be a more user friendly solution if you have confidence in your ability to distinguish between the two. Ultimately though, if someone has credentials they shouldn't the only answer is to cancel those credentials. Commented Mar 27, 2018 at 12:13

The basic method is to change cookie on a fairly regular basis - make it so that an attacker who obtains a cookie from your computer only has a limited period where it is valid. Even if the session is kept open for a longer time, you can replace the cookie which is associated with the session on a more regular basis.

In order to detect this type of abuse, services can also provide a list of active sessions, associated with IP address/device type/etc. This allows users to see if there are unexpected sessions open, and to close these.

It's also a good idea to ask for a second factor for every important action within the application (as @Xavier59 mentioned in comment) - these could be things like changing the password, changing the associated email address, or attempting to turn off 2FA.

  • 2
    how do you know if the cookie you are replacing is from the attacker or from the real user? Device type info can be easily faked in the request using the same one as the original user. Mobile users' IP changes very frequently that I don't think it could be used as a good identifier
    – Steve
    Commented Mar 26, 2018 at 16:02
  • 3
    You don't - hence the detection step. If the attacker can use the cookie within the validity period, they've got a perfectly valid session, which is probably pretty much indistinguishable from the legitimate one (especially if both users are using a corporate device from the same network). Only one of them will get the updated cookie though, if you're being careful and dropping sessions which try to use "old" values.
    – Matthew
    Commented Mar 26, 2018 at 16:05

You must log in to answer this question.

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