tomcat-dev mailing list archives

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

Although it is likely to get ignored / end up as WONTFIX. I don't see
what the security issue is here. How does an MD5 collisions affect the
security of the session ID?


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

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

View raw message