tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Minoo Hamilton <>
Subject Re: Why are manager session tokens generated with MD5 by default?
Date Mon, 05 Jan 2009 21:26:21 GMT
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?

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:

View raw message