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". >
