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 Tue, 06 Jan 2009 02:00:13 GMT
Perhaps, I am making a big deal over a small theoretical issue, but I 
don't think I am.  In my mind, if you're ever in a situation to 
guess/predict/brute force a valid and current session token, there are a 
range of session hijacking possibilities that are all potentially bad.  
If you'd really like to learn more about why it is a potentially big 
deal, I'm providing some references:

Credential/Session Prediction

"iDefense: Brute-Force Exploitation of Web Application Session ID's", By 
David Endler - iDEFENSE Labs

"Best Practices in Managing HTTP-Based Client Sessions", Gunter Ollmann 
- X-Force Security Assessment Services EMEA
[see: Brute Forcing]
"A Guide to Web Authentication Alternatives", Jan Wolter

Also see sections A5/A7/A8 of the OWASP Top 10 for 2007

A5 - Cross Site Request Forgery (CSRF) 

A7 - Broken Authentication and Session Management 

A8 - Insecure Cryptographic Storage 

    * *Do not* *create cryptographic algorithms*. Only use approved
      public algorithms such as AES, RSA public key cryptography, and
      SHA-256 or better for hashing.
    * *Do not* *use weak algorithms*, such as MD5 / SHA1. Favor safer
      alternatives, such as SHA-256 or better.


Minoo Hamilton

Mark Thomas wrote:
> 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?
> Mark
>> 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:

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

View raw message