[Esapi-user] ESAPI Random Number Generation Broken

John Melton jtmelton at gmail.com
Mon Apr 7 03:40:26 UTC 2014


The javadoc says it's threadsafe, to a fault (performance).

According to
http://www.cigital.com/justice-league-blog/2009/08/14/proper-use-of-javas-securerandom/,
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> 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?
>
>  -Jim
>
>
>
> 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
>>
>> --Jeff
>>
>>
>>
>>  On Apr 6, 2014, at 11:03 PM, "Jim Manico" <jim.manico at owasp.org> wrote:
>>>
>>> Jeff,
>>>
>>> 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,
>>> Jim
>>>
>>>
>>>  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.
>>>>
>>>> --Jeff
>>>>
>>>>
>>>> -----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
>>>>
>>>> Folks,
>>>>
>>>> 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
>>>> https://code.google.com/p/owasp-esapi-java/source/
>>>> browse/branches/2.1/src/main/java/org/owasp/esapi/
>>>> reference/DefaultRandomizer.java
>>>> 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.
>>>> https://code.google.com/p/owasp-esapi-java/issues/detail?id=323
>>>>
>>>> I believe this also may be the cause of
>>>> https://code.google.com/p/owasp-esapi-java/issues/detail?id=217
>>>>
>>>> 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
>>>> https://code.google.com/p/owasp-esapi-java/source/
>>>> browse/branches/2.1/src/main/java/org/owasp/esapi/
>>>> reference/DefaultRandomizer.java
>>>> 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.
>>>>
>>>> Regards,
>>>> Jim
>>>>
>>>>
>>>> _______________________________________________
>>>> Esapi-user mailing list
>>>> Esapi-user at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/esapi-user
>>>>
>>>
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-user/attachments/20140406/fa70fdf0/attachment.html>


More information about the Esapi-user mailing list