You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Minoo Hamilton <mi...@forkbolt.net> on 2009/01/05 22:26:21 UTC
Re: Why are manager session tokens generated with MD5 by default?
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
Re: Why are manager session tokens generated with MD5 by default?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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?
The only reason I can think of to apply it would be that md5 shouldn't
enter the equation as an algorithm on a FIPS-140 application. But since
anyone approaching this problem is trying to apply FIPS-140 to the SSL
communications layer, and that the session and user credentials are
probably not subjected to those rigours, you are possibly right.
The real answer as Filip suggests is to offer a patch, and find a committer
who will champion it and apply it for you :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Why are manager session tokens generated with MD5 by default?
Posted by Minoo Hamilton <mi...@forkbolt.net>.
Preston L. Bannister wrote:
> How would you reverse a session-id from an MD5 hash? The exploit used to
> forge an SSL certificate will not help you. The MD5 exploit is irrelevant to
> this particular usage.
>
> Lots of links and discussion:
> http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html
>
I'm fully aware that this is different, Preston. And I am certain that
there are many things I don't understand about security. All I meant to
point out by the reference was that the idea that MD5 collisions are
theoretical, based on the notion of computational expense, should now be
shattered.
> If you are connecting to *any web application* on a high-value target over
> an insecure network using HTTP (not HTTPS) then you already have a *Very
> Large Problem* (think about man-in-the-middle attacks). Changing the hash
> applied to session ids is not going to help.
>
Yes, but what I'm suggesting relates to brute forcing and session
hijacking scenarios. I totally agree that SSL definitely makes it all
much harder to pull off. Nonetheless, many sites have vulnerabilities
in how they handle these things (e.g. the recent Yahoo Mail problem), so
taking SSL for granted can be a problem, as well.
> Minoo, as a "security researcher" you should already be clear on the
> relative importance of differing risks, and cost/value ratios of exploits.
> Use of the MD5 hash as described is entirely harmless.
>
Thanks for the air quotes, Preston. The problem with your line of logic
is that it ignores asymmetries -- the thing you don't thing is a problem
that can sometimes be your biggest problem. I tend to treat things
equally till I'm certain, because risk does not follow a normal
distribution model, when it comes to vulnerabilities.
Anyhow, I have come to the Tomcat developer community to both be
supportive and to ask for help in determining if this is or is not a
real risk. Clearly you think it is not. I appreciate your feedback.
Minoo
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Why are manager session tokens generated with MD5 by default?
Posted by "Preston L. Bannister" <pr...@bannister.us>.
How would you reverse a session-id from an MD5 hash? The exploit used to
forge an SSL certificate will not help you. The MD5 exploit is irrelevant to
this particular usage.
Lots of links and discussion:
http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html
If you are connecting to *any web application* on a high-value target over
an insecure network using HTTP (not HTTPS) then you already have a *Very
Large Problem* (think about man-in-the-middle attacks). Changing the hash
applied to session ids is not going to help.
Minoo, as a "security researcher" you should already be clear on the
relative importance of differing risks, and cost/value ratios of exploits.
Use of the MD5 hash as described is entirely harmless.
On Mon, Jan 5, 2009 at 4:07 PM, Mark Thomas <ma...@apache.org> 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
> >>
> >> 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".
>
Re: Why are manager session tokens generated with MD5 by default?
Posted by Minoo Hamilton <mi...@forkbolt.net>.
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
http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml
"iDefense: Brute-Force Exploitation of Web Application Session ID's", By
David Endler - iDEFENSE Labs
http://www.cgisecurity.com/lib/SessionIDs.pdf
"Best Practices in Managing HTTP-Based Client Sessions", Gunter Ollmann
- X-Force Security Assessment Services EMEA
http://www.technicalinfo.net/papers/WebBasedSessionManagement.html
[see: Brute Forcing]
<http://www.itsecurity.com/papers/iss9.htm>
"A Guide to Web Authentication Alternatives", Jan Wolter
http://www.unixpapa.com/auth/homebuilt.html
Also see sections A5/A7/A8 of the OWASP Top 10 for 2007
http://www.owasp.org/index.php/Top_10_2007
A5 - Cross Site Request Forgery (CSRF)
<http://www.owasp.org/index.php/Top_10_2007-A5>
http://www.owasp.org/index.php/Top_10_2007-A5
A7 - Broken Authentication and Session Management
<http://www.owasp.org/index.php/Top_10_2007-A7>
http://www.owasp.org/index.php/Top_10_2007-A7
A8 - Insecure Cryptographic Storage
<http://www.owasp.org/index.php/Top_10_2007-A8>
http://www.owasp.org/index.php/Top_10_2007-A8
* *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.
PDF: http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf
Thanks,
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
>>>
>>> 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
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Why are manager session tokens generated with MD5 by default?
Posted by Mark Thomas <ma...@apache.org>.
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
>>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Why are manager session tokens generated with MD5 by default?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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
Re: Why are manager session tokens generated with MD5 by default?
Posted by "Preston L. Bannister" <pr...@bannister.us>.
First, note that any session-id provides only the flimsiest sort of
"security". Proper authentication was described a long time ago:
Needham, Roger; Schroeder, Michael (December 1978), "Using encryption
for authentication in large networks of computers.", *Communications of the
ACM* *21* (12): 993-999,
doi<http://en.wikipedia.org/wiki/Digital_object_identifier>
:10.1145/359657.359659 <http://dx.doi.org/10.1145%2F359657.359659>
When first reading up on security in the mid-1980's, I came across a series
of papers from Xerox PARC. I *think* this is one, though I do not have a
copy. The principle of using a "nonce" and a "digest" date back about this
far. The story is too long to write here. Might do a write up later.
There *is* a question worth asking here. Is the random number generator used
to generate session id's easily guessable? If so the applying a MD5 (or any
other hash function) may only make an attack a little more expensive. If the
random number generator used is decent and properly seeded, then (strictly
speaking) we do not need the hash function. Hashing the pseudo-random data
adds a little insurance - but only that. If flimsy security is good enough
(and sometimes it is) then session id's are good enough.
Changing the hash function is not going to make a significant difference.
On Tue, Jan 6, 2009 at 5:02 AM, Tim Funk <fu...@joedog.org> wrote:
> Just turning the random number into a session id should sufficient and we
> can forget the MD5 altogether. But if someone figures out the seed and can
> guess future subsequent numbers, then they can guess future session ids.
>
> By using a hashing algorithm - it makes it impossible to guess what numbers
> came from the random number generator.
>
> If MD5 is so broken that a person can piece together a long enough sequence
> of numbers to figure out the seed - and guess future session ids - then we
> need to replace it.
>
> But MD5 is not that broken.
>
> -Tim
>
>
> 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.
>>
>
Re: Why are manager session tokens generated with MD5 by default?
Posted by Tim Funk <fu...@joedog.org>.
Just turning the random number into a session id should sufficient and
we can forget the MD5 altogether. But if someone figures out the seed
and can guess future subsequent numbers, then they can guess future
session ids.
By using a hashing algorithm - it makes it impossible to guess what
numbers came from the random number generator.
If MD5 is so broken that a person can piece together a long enough
sequence of numbers to figure out the seed - and guess future session
ids - then we need to replace it.
But MD5 is not that broken.
-Tim
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org