[Esapi-user] ESAPI Random Number Generation Broken
jim.manico at owasp.org
Mon Apr 7 03:03:34 UTC 2014
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
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
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