I considered checking the session id first and skipping the ip check if it was valid. But if I were to do that, then there's really no point to checking ips at all. An attacker could simply scream through session ids until an active one was found.
| [reply] |
I make my session IDs 64 bits long. Even if they could check 1 million/sec, it would still take more than 5000 years before they could have even a 1% chance of finding one.
| [reply] |
Well, my session id is suitably big enough, and random (or as random as the random function makes it). And you're absolutely right about the length of time needed to roll through them all. Maybe that's enough?
| [reply] |
Why not store the IP address in the session id as well. Even if some were to brute force a session ID they would also have to know the IP address being used by that particular session. That would be harder to crack than just a session ID.
| [reply] |
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] |