My web service is an API-driven Single-Page-Application. Once the user logs in they're given a temporary token to use for the rest of the session which is sent along with each API request. The token is of course tied to the IP address that performed the login request. This means that even if a 3rd party somehow managed to capture a token despite TLS, they probably couldn't use it and it wouldn't be usable by anyone at all after the current session ended.

But I recently came across a user whose IP address changes with extreme frequency (as frequently as every 30 minutes) causing them to frequently need to re-log-in while using the service. The address change is caused by on-campus dorm internet that recycles a very limited pool of IP addresses that the end-user of course has have no control over.

How can I reconcile keeping the security of my current setup, while also not causing users in this situation grief? The best 'middle-ground' I've got so far is loosening the IP requirement to only match the first octet of the address, but that's far from ideal.

  • Are you able to allow IP ranges? For example, 192.168.1.* instead of From my perspective, it also seems like relying on this IP address method is pointless. – Mark Buffalo Feb 4 '16 at 17:45
  • How about adding an option (possibly in the user's Account configuration) to grant longer lived sessions? – Purefan Feb 4 '16 at 17:45
  • @Purefan It's not the session length that's the issue, this isn't a 'remember me' tag - this is while the SPA is still open in the browser in the same session. The users IP changes and suddenly their login token isn't valid anymore because the service sees them as coming from a different IP address. – PhonicUK Feb 4 '16 at 17:47
  • @MarkBuffalo These are coming from external IPs and the range of change is really wide, for this particular user the last 3 octets change - if I allowed a range that wide I might as well not bother caring what IP address requests come from and only care about the token - but that's a step down security wise. – PhonicUK Feb 4 '16 at 17:49
  • @PhonicUK Yeah, I used a local IP as an example, not internal ones. Sorry, should've clarified that. – Mark Buffalo Feb 4 '16 at 17:51

I am inclined to say that the bit about tying the session token to the source IP address is harmful and should be removed.

Such a tying is often reported as "good for security", but exactly why it is good for security is rarely explained. It is similar, in that respect, to the widespread recommendation for changing your passwords regularly: a well-entrenched Tradition, for reasons that nobody quite remembers, and with toxic side-effects.

The main reason why session tokens are to be tied to an IP address is not to prevent reuse after theft through the TLS layer. Let's face it: if an attacker could break through the TLS, then a filter on the IP address won't block him either. Such an attacker could so much hijack the user's connection that he totally owned it; masquerading with the user's usual IP address will not deter such an attacker.

The real reason for tying the session token to the IP address is to try to prevent a user from sharing his token with all his friends. This is a commercial issue, similar to software licensing. It is normally best addressed with surveillance: instead of blocking session tokens that do not come from the same IP address as previously, you should merely log such an attempt (but still allow it), and, asynchronously, investigate situations where a token appears to be used by too many source IP addresses.

  • There's nothing stopping the user from logging in multiple times in multiple locations, that's fine - the token is used purely for the integrity of the current active session in an open (and remaining open) browser window. But I get your point that if the login token has been stolen it's probably too late to care about measures anyway. – PhonicUK Feb 5 '16 at 12:29
  • 1
    I completely agree that tying security to the IP address is the wrong approach and isn't providing the integrity you may think it is. NAT is extremely common and many people and devices will have the same IP address. Likewise with somebody walking around a business or campus or walking out of their house, where their IP address may change as they hop around to different network nodes or even different internet providers (wifi to 4G and back, for example). – Craig Oct 18 '16 at 4:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.