[Esapi-user] ESAPI Random Number Generation Broken

Jim Manico jim.manico at owasp.org
Wed Apr 9 13:11:23 UTC 2014


Care to give it a try and toss us a patch, Bruno?

Aloha,
--
Jim Manico
@Manicode
(808) 652-3805

On Apr 9, 2014, at 8:24 AM, Bruno Girin <bruno at energydeck.com> wrote:

Hi,

I'm a newby on this list so apologies if the comments below are out of
place but I thought I would contribute to the discussion.

On 9 April 2014 05:17, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:

>   BTW, I figured out a way to do that without
> using the potentially biased [Secure]Random.nextInt(int) call. It's just:
>
>     byte[] nonce = new byte[ n ];
>     secureRandom.nextBytes(nonce);
>     StringBuilder result = new StringBuilder(length);
>     for( int i = 0; i < nonce.length; i++ ) {
>         char c = characterSet[ Math.abs( (nonce[i] % characterSet.length)
> ) ];
>         result.append( c );
>     }
>     return result.toString();
>
> I added two characters ('_' and '.', but any additional 2 unreserved
> characters from RFC 3986 - Section 2.3 would do) to the 62 characters
> (A-Z, a-z, and 0-9) that ESAPI was using just to get rid of potential bias
> (since 64 divides 256).


[Secure]Random.nextBytes(byte[])  is the most efficient way I know to do
this in Java. With regards to base 64, RFC 2045 [1] specifies that the 2
additional characters are + and / and that = is used for padding.

Having said this, rather than code the base 64 algorithm in ESAPI (and
having to maintain that code), what about using one that already exists,
namely the Apache Commons Codec one? [2]

[1] http://www.ietf.org/rfc/rfc2045.txt
[2]
http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html

Cheers,

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-user/attachments/20140409/e79c912c/attachment.html>


More information about the Esapi-user mailing list