In the past, I've used symmetric crypt key lengths as a comparison,
but am I being too tough on the developer? I'd like to have some
justification behind a finding that says, "Your session ID size of XX
bits is not big enough".
By having the same entropy as used in your SSL layer, you should be
safe, since as you note, online brute forcing is much slower.
So here are the factors that I've come up with (for the purposes of
this discussion, lets assume we've got a decent PRNG that is
generating the session IDs):
- How many concurrent sessions does the web application usually have?
(this is important if the attacker is happy to hijack *any* session,
as opposed to a *specific* session)
- Session expiration timeout and typical length of a user session
(important if the attacker is looking to hijack a specific session)
- How many concurrent guesses could the web app sustain before
crashing? (ie. will 50,000 guesses/sec from my bot army crash the
server long before I can hijack a session?)
- Is the web app infrastructure protected by an IPS product (that works)?
So, does anyone out there have any good algorithms/calculations for
justifying a particular amount of entropy in a session ID?
Well, if you can find out the things above, then try to find out those
same parameters for an offline attack against a 128 bit key. Then
adjust your session ID length such that the time to crack is
approximately the same.
Of course, it's just easier to make them use a 16 measly bytes of (good)
entropy in their cookies, but if you do perform the calculation with
reasonable parameters, I'm sure some of us would be interested in your
results. =)
cheers,
tim
