Log user out after change of IP address?

Question

Does it make sense to log a user out from a web service after the user's IP address is changed?

I understand that a change of an IP address might indicate a man-in-the-middle attack. Then again IP addresses of end user devices (mobile phones) might change frequently when switching from network provider to local WLAN.

I personally think that adding a logout mechanism like this would not really add to the security of a website.

What aspects do I need to consider to make a solid decision about whether to use such a logout mechanism or not?

Answer 1

If you want to implement a security measure, you need to know what you secure yourself against. In this case, you want to secure yourself against a Man-in-the-Middle attack.

As you said yourself, a change of IP address is not a good indicator for that, for actually two reasons:

• There are many reasons why an IP address would change for legitimate reasons, such as the user gaining or losing a Wi-Fi connection, the user connecting to a VPN, etc. As such, this alone is a really bad indicator for an attack.
• For the detection to work, it assumes that a user first starts a session on their own, and is then intercepted by the Man-in-the-Middle. If your user is already being intercepted, the IP of the Man-in-the-Middle is the only IP you will ever see.

As such, this security measure is rather prone to false-positives and false-negatives, making it rather unreliable.

---

But there is a security measure employed by Google that works in a similar way. It detects the usual behavior patterns of a user, such as the usual locations and IP address ranges they connect from. Should a login deviate from this pattern, a security alert is triggered.

This is most prominent when users want to check their emails on vacation or similar, but can truly be an indicator of possible compromise if the user's regular usage patterns are clearly established.

This should be an example as to how information from IP addresses (and other sources) can be used to analyze behavior and thus detect anomalies. Anomaly Detection is a field all on it's own, so don't expect a comprehensive introduction in one paragraph. This example should merely serve illustrative purposes.

Answer 2

The only consideration is the one of risk.

Controls (like this control) are put in place to mitigate risks. What risks are you trying to mitigate? You say that it might mitigate MitM. Ok. Is that your web service's responsibility to do that? Does it make sense for the service to do that?

Then let's consider the actual scenario. Your control mitigates MitM if the attack happens after the user has already logged in. That's pretty specific and a really limited threat. Let's keep running the scenario. The attack happens and the service logs the user off, then the user logs back in. But the attack is still happening. So, now the attacker captures the login process and the password. Have you met the goal of the control? Some of these things might be mitigated by other controls you might have in place.

Also consider the risks of poor usability. If you install a control that makes it difficult for users to use your system, then you run the risks of losing users.

What is the best decision for you is up to you and all the factors you can't include in a question on a Q&A site.

Risk assessments are really straightforward. You just need to slowly connect the dots one by one and resist the temptation to jump to the end.

Answer 3

Hard no.

Security considerations aside (which this practice does not really help), restricting a session to an IP address utterly breaks access for users of some ISPs, especially mobile, who cycle IP addresses frequently. IPv6 even has features to do this intentionally for privacy. Unless you know your userbase well and know that none of them will be affected by such issues, it's a complete non-starter.

Answer 4

This used to be a thing with e.g. PHP sessions some 20 years ago. Quite possibly with everything else too as they used similar/identical mechanisms, but I remember the mitigation feature from PHP. You'd just enable it in the config.

The problem: You log in and get a session cookie (possibly embedded in the URL, even), and someone else could in theory eavesdrop that information and henceforth make requests on your behalf.

Now, of course, nobody uses HTTP any more, and HTTPS fixes that issue. You don't get to trivially send requests on behalf of someone else anymore (well unless you've installed a fake cert or subverted the network stack, or such).

Also, some more recent being-developed high-profile protocols (think QUIC) explicitly separate connections from addresses with the possibility of the IP address changing legitimately. Apparently, if there is a security risk involved, it's not so severe as to bother anyone at Google or IETF.

So... in short... no worries.