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
