tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
Subject Re: [Tomcat 4] Initializing PRNGs for Session Identifiers
Date Thu, 13 Sep 2001 05:08:37 GMT
> 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


Mime
View raw message