tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
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
>
> http://www.win.tue.nl/hashclash/rogue-ca/
>
> 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: http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html
>>>
>>> |algorithm|
>>>
>>> Name of the /Message Digest/ algorithm used to calculate session 
>>> identifiers produced by this Manager. This value must be supported 
>>> by the |java.security.MessageDigest| class. If not specified, the 
>>> default value is "MD5".
>>>  
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message