My web-app has this secret place only some people are allowed to use. When a user logs in to my secret place, I try gather as much information from them as I can, concatenate it, hash it, and send it as a cookie. Information such as : User Agent, IP Adress, Users’s password, plus a few more…
When a client requests anything, I regenerate all those things, hash them, and compare them to the cookie the clients sends me.
If some guy steals the cookies, they will probably have different User-Agents from the guy who legally logged in, and the hashes wont match, not letting him in.
If some older-wiser-guy fakes all the http headers, i’ll see the IP address mismatch and the hash wont match.. not letting him in.
There is where my problem resides, what should I do if my legally logged in client loses internet connectivity and the re-establishes it with another IP Adress as his/her ISP leases dynamic IP’s. My current algorithm will say “Aha ! This is an attacker ! Close this session !”.
This secret place is better if not disrupted for valid users, and since, for some reason internet connectivity has been intermittent the last couple of weeks, my users find uncomfortable the fact that the application requires them to re-login every time their IP changes.
Should I discard the IP validation ?
Trying to impose security by obscurity or security by complexity is often more prone to exploitation than simple, well-understood security measures.
You have correctly identified that fixing a session to an IP can be a detriment to user experience. You have to decide whether this inconvenience(especially for TOR or other anonymization and mobile network users) is worth the additional security.
Bear in mind that an attacker who can intercept communication between your server and the client can likely also communicate with the client’s IP address. It is trivial if he’s in the client’s LAN, and otherwise still simple. So in essence, you’re defending against the nearly-empty set of attackers who are totally incompetent and yet can intercept network traffic in relatively secure high-bandwidth networks (your local installation or core internet routers).
If security is really such an issue – and it’s usually not unless you’re running a bank, large company, or military-ish organization – better use SSL, check your website for common vulnerabilities, and secure client computers.