java.util.Random does not have enough entropy to be used for security purposes.
IIRC the sequence can be repeated as the seed is based on the epoch, and so is
predictable.
You could use it, but the keys would be predictable and since these keys are
used to generate the HMACs for all user logins, then it would be relatively
easy to zero in on the key by watching generated HMACs and looking for the
points at which they change, and expire.
If there was 1 key for all time, even SecureRandom would not be good enough,
which is why the keys rotate every 5 min and expire after 30min (configurable).
So, in this instance we have to use SecureRandom.
----------------------------------------------------------------------------
The problem is down to the configuration for SecureRandom on the OS platform.
And the way we get an instance. I think we do getInstance(SHA1PRNG), but that
might be a mistake as it will force the JRE to use that one, (see notes on [1])
IIRC on Solaris and Linux un.security.provider.NativePRNG is used which binds
to /dev/urandom or equiv. On WIndows SHA1PRNG is used. also IIRC SHA1PRNG will
use the OS's random generator to provide the seed, so whatever PRNG you use, it
will always need a seed and the seed is OS depenant
You can set the source using securerandom.source in the JRE or
-Djava.security.egd=file:/dev/urandom on the command line.
However, there are some JRE bugs in various versions, see [1].
Can you try running the following 2 tests on you OS to see if there is any
difference.
import java.security.SecureRandom;
public class Test {
public static void main(String args[]) throws Exception {
SecureRandom rnd = SecureRandom.getInstance("SHA1PRNG");
for (int i=0; i < 1000; i++) {
rnd.generateSeed(256);
System.out.println("Got " + i);
}
}
}
and
import java.security.SecureRandom;
public class Test2 {
public static void main(String args[]) throws Exception {
SecureRandom rnd = SecureRandom.getInstance();
for (int i=0; i < 1000; i++) {
rnd.generateSeed(256);
System.out.println("Got " + i);
}
}
}
HTH
Ian
1
http://bugs.sun.com/view_bug.do;jsessionid=e1244ca9c599cffffffffd8eb336175a921b?bug_id=6202721
On 3 Sep 2010, at 22:25, Felix Meschberger wrote:
> Hi all,
>
> I noticed slow (extremely slow, actually: something like 30seconds)
> startup of the Form Authentication Handler [1]. Tracking this down I
> found, that the SecureRandom implementation uses /dev/random which may
> block indefinitely to gather enough entropy to ensure secure random byte
> stream.
>
> Now, a local quick hack solution is to create a symbolic link from
> /dev/urandom to /dev/random. But I don't think this is the right
> solution in the long run -- and I doubt this is a viable solution on a
> server system.
>
> I wonder, whether we really new SecureRandom here or whether
> java.util.Random would just be random enough ?
>
> Do others have experience with this ?
>
> (ah, Sun has a whole range of bugs for this /dev/random issue)
>
> Regards
> Felix
>
>
> [1] https://issues.apache.org/jira/browse/SLING-1729
