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] |
I think the Session ID should be based on multiple time-dependant sureties and not a random value as there is a possibility, however small or unpredictable, that two calls to rand() might return the same value. If a session is based on time, surely it makes sense to use a time-dependant value in choosing a session ID.
As to how big a session ID string should be, well big enough to ensure that there are no session-ID collisions within the lifetime of your application. A SHA1 hash of a few values quite surely suffices but might not be ideal due to the overhead required in calculating the hash. Maybe some other hashing algorithm that is less-resource intensive?
perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er
| [reply]
[d/l]
[select] |
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] |
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] |