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?

  • 16
    Home internet connections often change IP address as well. I recorded it and my home IP address changes every 1-4 days.
    – Qwertie
    Commented Oct 30, 2019 at 3:05
  • 21
    You can even have people that stay on the same network but will have their connections go through load-balanced NAT devices or proxies which will make them appear to switch IPs in consecutive connections.
    – jcaron
    Commented Oct 30, 2019 at 8:56
  • 2
    It's meant to protect the user, not the website.
    – Edheldil
    Commented Oct 30, 2019 at 11:45
  • 3
    It is an add on to the security of the user, I've seen many sites mostly banking one implemented such solutions. Point that need to be taken here is iIP can not be used as the Identity of the user. Also it will be definitely a bad UX for customers.
    – avicoder
    Commented Oct 30, 2019 at 16:23
  • 1
    We once used a bank that logged us out every few clicks because our internet connection is load balanced. Fortunately we're not using that bank anymore. I also remember Typo3 doing the same but I think they fixed it long ago.
    – AndreKR
    Commented Oct 31, 2019 at 11:19

4 Answers 4


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.

  • Amazon does the same. If you login into amazon from a random place it will ask you to re-enter your credit card details to confirm that it's you when trying to pay for something. Commented Oct 29, 2019 at 17:04
  • 7
    Multipath TCP (RFC 6824) would be another reason your IP changes a lot during the same session.
    – schlenk
    Commented Oct 29, 2019 at 18:00
  • 10
    Reason three: for some types of man-in-the-middle attacks, the IP actually stays the same.
    – Bergi
    Commented Oct 30, 2019 at 0:39
  • @Bergi yes, very important point. If the MITM comes in before the user exits to your network with an IP (e.g., MITM in the local network before going out the local router), then you'd get the same IP. The MITM can intercept the request before or at a proxy, as well and just route the request through the same proxy thus appearing to have the same IP. All in all, IP (as very often) it's not a very reliable measure to identify somebody. At the very least, not taken by itself.
    – VLAZ
    Commented Oct 30, 2019 at 8:24
  • 1
    I thought that logout-on-IP-change was implemented as a defense against session (cookie) stealing, not MITM. If the cookie was short-lived, it makes sense to bind it to a specific IP address.
    – Edheldil
    Commented Oct 30, 2019 at 11:44

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.

  • "Risk assessments are really straightforward" do you have a book or resource you recommend to improve one's ability to systematically assess risk the way you describe?
    – ig-dev
    Commented Nov 2, 2019 at 7:07
  • There are numerous methodologies and frameworks for IT risk.
    – schroeder
    Commented Nov 2, 2019 at 9:21
  • Yes I'm sure. I just like the way you approach risk assessments and would like develop that skill. I think there is not really a right or wrong answer to my request. If you have any recommendation, I'd appreciate it.
    – ig-dev
    Commented Nov 2, 2019 at 9:34
  • 1
    FAIR, is growing in popularity right now. You should also look at Value at Risk as an approach instead of heat maps (heat maps are never the right approach) and learning how to frame/phrase a risk. Then tieing it all to org values/goals/objectives/fears.
    – schroeder
    Commented Nov 2, 2019 at 9:58

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.


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.

You must log in to answer this question.

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