[Esapi-user] ESAPI Random Number Generation Broken
jim.manico at owasp.org
Mon Apr 7 04:10:34 UTC 2014
Supposedly, the only reason you need to reseed is because an attacker
who can see *many* random values from the same SecureRandom instance has
an increasingly better chance to determine the seed. Once the attacker
can determine the seed, the attacker can determine the PRNG sequence.
However, this does not explain why Rook reported that 20,000 calls to
the same instance ESAPI's Randomizer popped up as deterministic in the
Burp analysis tool.
However, *periodic* reseeding like you suggest seems more than
appropriate, regardless of what our code archeology discovers. :)
On 4/6/14, 8:40 PM, John Melton wrote:
> The javadoc says it's threadsafe, to a fault (performance).
> According to
> , the same instance shouldn't be used forever. You can either
> periodically re-seed, or periodically throw away the instance and
> re-instantiate. Probably reasonable to reset the secure random every
> 50/100/500 calls (maybe another config option - oh joy!)
> On Sun, Apr 6, 2014 at 11:23 PM, Jim Manico <jim.manico at owasp.org
> <mailto:jim.manico at owasp.org>> wrote:
> The problem is not thread safety, the original report had basic
> code that just returned 20,000 values from the ESAPI Randomizer
> API using the default configuration (SHA1PRNG) which came out
> non-random according to Burp's analyzer at the time.
> Several of my clients at the time acknowledged the same problem
> with ESAPI-Java and also used burp for analysis. We "fixed" it by
> just using new SecureRandom instances for CSRF tokens and other
> random number needs. I believe most of the ESAPI crypto API is
> using it's own internal SecureRandom instances.
> Perhaps the problem is Burp's random analyzer?
> On 4/6/14, 8:11 PM, Jeff Williams wrote:
> Checked into SecureRandom and it appears to be thread safe.
> It's even documented in Java7.
> The nextInt issue is just a javadoc problem. Should say
> "exclusive" like the underlying nextInt call
> On Apr 6, 2014, at 11:03 PM, "Jim Manico"
> <jim.manico at owasp.org <mailto:jim.manico at owasp.org>> wrote:
> I had a phone call with Kevin this evening and we are not
> sure if the problem is the single instance of
> SecureRandom, or perhaps some problem from the encoding,
> or maybe an OS level issue (since SecureRandom has
> different behavior [even with the same algorithm and seed]
> on different JVM's/OS's), or some other error that we have
> not figured out yet. Also check out the related bug
> which seems rather glaring (same value returned every
> time) we will investigate this as well.
> The test case is simple - use ESAPI to generate a sequence
> of random values and run it through a well vetted random
> number analyzer, but we'll provide specific code for this
> David Rook provided the initial analysis and used Burp's
> random number analyzer. The bug is entered here
> and we will track our progress there. Kevin and I intend
> of find and fix the problem ASAP.
> More soon,
> On 4/6/14, 7:45 PM, Jeff Williams wrote:
> Could you share the test case please? Are you
> suggesting that it is not safe to use a single
> instance of SecureRandom?
> Does the test rely on the nextInt( a, b ) call? I
> think the Javadoc for that method is broken and
> should say the max is *exclusive* -- mirroring the
> behavior of the Java random.nextInt( x ) call.
> -----Original Message-----
> From: esapi-user-bounces at lists.owasp.org
> <mailto:esapi-user-bounces at lists.owasp.org>
> [mailto:esapi-user-bounces at lists.owasp.org
> <mailto:esapi-user-bounces at lists.owasp.org>] On Behalf
> Of Jim Manico
> Sent: Sunday, April 06, 2014 6:54 PM
> To: esapi-dev at lists.owasp.org
> <mailto:esapi-dev at lists.owasp.org>;
> esapi-user at lists.owasp.org
> <mailto:esapi-user at lists.owasp.org>
> Subject: [Esapi-user] ESAPI Random Number Generation
> Over a year ago the ESAPI team got a report from David
> Rook that the ESAPI Random Number Generator was not
> providing a random sequence of values. Using burp's
> random number analyzer, he found that ESAPI was
> providing a very predictable sequence of numbers from
> class. I was asked not to report on this to give the
> team time to fix it, but it's been over a year or
> more. So I reported it officially today.
> I believe this also may be the cause of
> This also impacts anyone using ESAPI for Java for CSRF
> protection. Your CSRF tokens are not true random, they
> are a predictable sequence of numbers that will make
> it easier for an attacker to guess your CSRF token
> value. This also impacts key creation in the crypto
> API's. This also impact the random access map in ESAPI.
> A quick fix is to fork
> class and create a new instance of SecureRandom for
> each use. Be sure to test the performance impact of this.
> Any questions, drop me a line here or at
> jim.manico at owasp.org <mailto:jim.manico at owasp.org>.
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> <mailto:Esapi-user at lists.owasp.org>
> Esapi-user mailing list
> Esapi-user at lists.owasp.org <mailto:Esapi-user at lists.owasp.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user