[Esapi-user] ESAPI Random Number Generation Broken
jtmelton at gmail.com
Mon Apr 7 03:40:26 UTC 2014
The javadoc says it's threadsafe, to a fault (performance).
the same instance shouldn't be used forever. You can either
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> 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> 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 https://code.google.com/p/
>>> owasp-esapi-java/issues/detail?id=217 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 soon.
>>> David Rook provided the initial analysis and used Burp's random number
>>> analyzer. The bug is entered here https://code.google.com/p/
>>> owasp-esapi-java/issues/detail?id=323 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:[email protected]
>>>> lists.owasp.org] On Behalf Of Jim Manico
>>>> Sent: Sunday, April 06, 2014 6:54 PM
>>>> To: esapi-dev at lists.owasp.org; esapi-user at lists.owasp.org
>>>> Subject: [Esapi-user] ESAPI Random Number Generation Broken
>>>> 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 the
>>>> 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.
>>>> Esapi-user mailing list
>>>> Esapi-user at lists.owasp.org
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user