> BACKGROUND:
> * An optional entropy-increasing string value that you can specify
> in your "conf/server.xml" file, like this:
>
> <Context ...>
> ...
> <Manager entropy="My Private Entropy String"/>
> ...
> </Context>
>
> If no entropy property is specified, a default (and therefore
> predictable) entropy string is used.
>
> This approach has the advantage of seeding much more quickly, but the
> disadvantage that the sequence of session ids is potentially predicatable.
> Predicatability is *much* easier if an attacker can manage to read
> "conf/server.xml" (although, as I've pointed out to Christopher, security
> of your session ids is the *least* of your problems if this happens). The
> current approach is also the one that was recommended the last time this
> issue was raised (when Tomcat 3.1 had a *very* weak approach to
> calculating session ids).
>
> The decision we face, of course, is whether or not to change this. A
> complicating factor is that some platforms offer facilities (such as
> /dev/random) to take advantage of entropy gathered by the OS -- but such
> things are obviously not portable, so they cannot be relied on to satisfy
> all requiremnts.
>
> It seems to me we have a number of overlapping decisions. My thoughts are
> after each decision area -- I'm looking for input from others.
>
>
> DECISION 1 - WHAT SEEDING MECHANISMS SHOULD WE SUPPORT?
>
> (1A) Default seeding of java.security.SecureRandom (time consuming but
> reasonably secure)
>
> (1B) Current mechanism of timestamp + entropy string (very fast,
> potentially not secure)
I think the current mechanism is good enough. With a carefully chosen
secret, I don't see how that could be cracked, and if it turns out it's
actually doable, it must be a lot easier to try to find another way in.
Also, maybe we can find a way to slightly improve the randomness of the
seed.
> (1C) Plug-in seeding API to allow use of platform-specific algorithms
> if desired
The plugin mechanism looks like a very good idea, and we should implement it
in the next maintenance release of Tomcat 4.
> Currently, Tomcat 4 only supports (1B). It certainly makes sense to offer
> (1A) as well. Offering (1C) is more work, but is not conceptually
> difficult.
>
>
> DECISION 2 - WHAT SEEDING MECHANISM SHOULD BE THE DEFAULT?
> (assumes, of course, that we support them both)
>
> (2A) Default seeding
>
> (2B) Current mechanism
>
> Currently, (2B) is supported, because only (1B) is supported. This is
> likely to be a much more involved discussion that Decision 1. I could be
> persuaded to (2A), but I'm not really certain that this is an issue in the
> majority of Tomcat installations -- if we allow people who care about it
> to choose (2A), but not make people suffer when they don't feel session id
> predicatability is an issue, that seems like a reasonable approach.
The security level provided by 2B seems enough in 99% of the cases, so I
would leave it as the default.
> DECISION 3 - WHAT PLUG-INS FOR (1C) SHOULD WE OFFER AS STANDARD?
>
> (3A) Unix systems /dev/random
>
> (3B) Unix systems /dev/urandom
>
> (3C) ???
>
> Currently, none of these are supported.
We probably will have to start a modules repository to put that kind of
additional features.
Remy
