My first reaction to this is that only helps by making the session ID 4 bytes larger (and granted more combinations to try).
But maybe I can use that in some way. If the IP contained in the session ID doesn't match the client IP, then I can immediately drop through the IP block without bothering to check for a valid session id. Maybe save a session id lookup step before dropping the client. That's good!
It doesn't do anything to prevent malicious users from inside the routed network but it looks like this is a risk I may have to live with. Maybe half a solution is better than no solution. | [reply] |
At some places--for example where I work--there are multiple redundant HTTP proxy servers. So the IP address may be different on each request.
This also happens (or at least used to) with AOL users.
Plus, most people use dynamic IP addresses, which change from time to time. Even though it may be just once a month or so, the user may be confused if they suddenly have to log in again. If they're completely blocked ... well, don't do that.
| [reply] |
So is my only option to literally forget the whole ip blocking strategy?
| [reply] |