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-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
