> 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
|