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