tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Preston L. Bannister" <pres...@bannister.us>
Subject Re: Why are manager session tokens generated with MD5 by default?
Date Tue, 06 Jan 2009 01:44:41 GMT
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 <markt@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".
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message