[Esapi-user] ESAPI Random Number Generation Broken
jim.manico at owasp.org
Mon Apr 7 03:23:51 UTC 2014
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
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: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; 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 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
>>> 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
More information about the Esapi-user