First, note that any session-id provides only the flimsiest sort of
"security". Proper authentication was described a long time ago:
Needham, Roger; Schroeder, Michael (December 1978), "Using encryption
for authentication in large networks of computers.", *Communications of the
ACM* *21* (12): 993-999,
doi<http://en.wikipedia.org/wiki/Digital_object_identifier>
:10.1145/359657.359659 <http://dx.doi.org/10.1145%2F359657.359659>
When first reading up on security in the mid-1980's, I came across a series
of papers from Xerox PARC. I *think* this is one, though I do not have a
copy. The principle of using a "nonce" and a "digest" date back about this
far. The story is too long to write here. Might do a write up later.
There *is* a question worth asking here. Is the random number generator used
to generate session id's easily guessable? If so the applying a MD5 (or any
other hash function) may only make an attack a little more expensive. If the
random number generator used is decent and properly seeded, then (strictly
speaking) we do not need the hash function. Hashing the pseudo-random data
adds a little insurance - but only that. If flimsy security is good enough
(and sometimes it is) then session id's are good enough.
Changing the hash function is not going to make a significant difference.
On Tue, Jan 6, 2009 at 5:02 AM, Tim Funk <funk...@joedog.org> wrote:
> Just turning the random number into a session id should sufficient and we
> can forget the MD5 altogether. But if someone figures out the seed and can
> guess future subsequent numbers, then they can guess future session ids.
>
> By using a hashing algorithm - it makes it impossible to guess what numbers
> came from the random number generator.
>
> If MD5 is so broken that a person can piece together a long enough sequence
> of numbers to figure out the seed - and guess future session ids - then we
> need to replace it.
>
> But MD5 is not that broken.
>
> -Tim
>
>
> Minoo Hamilton wrote:
>
>> I'd like to re-raise an issue, since I didn't get too much of a response,
>> originally. Who can I talk to to lobby to get the default behavior of using
>> MD5 session token hashes to change? If you weren't aware of it, there has
>> been a recent and highly-publicized breaking of SSL, by creating a rogue
>> certificate authority, using collisions in MD5. Creating collisions in MD5
>> are no longer a "highly theoretical" attack for potential session hijacking.
>> I'd very much like to see the default behavior of Tomcat session tokens
>> become more secure by default (possibly SHA-256). I think the default
>> hashing algorithm should not be a known broken and insecure one.
>>
>
