tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Why are manager session tokens generated with MD5 by default?
Date Tue, 06 Jan 2009 00:00:55 GMT
you don't need to lobby, simply create a patch in Bugzilla

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.
> MD5 considered harmful today
> Creating a rogue CA certificate
> Any thoughts?
> Thanks,
> Minoo Hamilton
> Tim Funk wrote:
>> It is probably due to old code which works just fine when SHA might 
>> not have been "easily available" in all JVM's. (back in 2002?)
>> So a quick recap for folks ... a session id is generated by
>> 1) Getting a random number
>> 2) Hashing it
>> 3) Converting the hashed bytes to something text [base64] so they fit 
>> in a cookie without extra work
>> Steps 1-3 are repeated until enough chars are present for the 
>> configured  session ID length.
>> So if an attacker *could* get reverse of the hash - it would be a 
>> random number. SessionId length is configurable - so you could change 
>> your session length to be larger so that mulitple random numbers 
>> become digested. And then keep the session length small enough so 
>> that next hash is not completely concatenated into the id. So at best 
>> the attack has a one full hash plus part of a another hash to work 
>> with. (As of this writing - I cant recall how times digest is called 
>> by default so I'm not sure if a single full hash is in the session 
>> id, or part of one, or multiples)
>> *** BUT *** If the random number and entropy to get the random number 
>> are "good enough" - hashing is already overkill. But in the case 
>> where the entropy and random number generator are "bad" - hashing 
>> provides another line of defense against determining the current 
>> random number and then being able to guess the next random number.
>> -Tim
>> Minoo Hamilton wrote:
>>> Greetings Tomcat Developers,
>>>  I am a security researcher who has recently been getting into 
>>> Apache Tomcat security hardening.  Forgive me if my failed attempt 
>>> to find the answer to this question has brought me prematurely to 
>>> this list.  I've been trying to figure out why the Apache Tomcat 6 
>>> Manager component defaults to using the MD5 hash algorithm for 
>>> session token creation.  It has long been seen as a questionable 
>>> hash algorithm due to known collisions.  Why not use SHA-1 by 
>>> default, instead?  Has anybody looked at SecureRandom which uses 
>>> SHA-1?  I assume eventually this should be SHA-2, as SHA-1 is coming 
>>> under increasing fire, as well.
>>> From:
>>> |algorithm|
>>> Name of the /Message Digest/ algorithm used to calculate session 
>>> identifiers produced by this Manager. This value must be supported 
>>> by the || class. If not specified, the 
>>> default value is "MD5".
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message