Please don't mark it as duplicate. It is a follow up question for both these questions.

Tomcat7 starts too late on Ubuntu 14.04 x64 [Digitalocean]
https://stackoverflow.com/a/2325109/6785908

I understand that, replacing

securerandom.source=file:/dev/urandom

with

securerandom.source=file:/dev/./urandom

in $JAVA_PATH/jre/lib/security/java.security will solve this problem.

My question is, is it ok to do so in production? Will this have any impact on security (like Session ID becoming predictable)? If this is less secure, is there any other way to give enough entropy quicker?

Update

I use openstack for deployment (or let's just say, uses AWS or GCP or any other cloud provider). So, adding a hardware device such as soundcard is not an option for me.

回答1:

After some extensive Googling with the right search terms, I came across this nice article on DigitalOcean. I am merely quoting the relevant part here.

There are two general random devices on Linux: /dev/random and /dev/urandom. The best randomness comes from /dev/random, since it's a blocking device, and will wait until sufficient entropy is available to continue providing output. Assuming your entropy is sufficient, you should see the same quality of randomness from /dev/urandom; however, since it's a non-blocking device, it will continue producing “random” data, even when the entropy pool runs out. This can result in lower quality random data, as repeats of previous data are much more likely. Lots of bad things can happen when the available entropy runs low on a production server, especially when this server performs cryptographic functions.

So, its a potential security risk.

Solution for Populating Entropy Pools

Linux already gets very good quality random data from the different hardware sources, but since a headless machine usually has no keyboard or mouse, there is much less entropy generated. Disk and network I/O represent the majority of entropy generation sources for these machines, and these produce very sparse amounts of entropy. Since very few headless machines like servers or cloud servers/virtual machines have any sort of dedicated hardware RNG solution available, there exist several userland solutions to generate additional entropy using hardware interrupts from devices that are “noisier” than hard disks, like video cards, sound cards, etc. This once again proves to be an issue for servers unfortunately, as they do not commonly contain either one

Solution: haveged

Based on the HAVEGE principle, and previously based on its associated library, haveged allows generating randomness based on variations in code execution time on a processor. Since it's nearly impossible for one piece of code to take the same exact time to execute, even in the same environment on the same hardware, the timing of running a single or multiple programs should be suitable to seed a random source. The haveged implementation seeds your system's random source (usually /dev/random) using differences in your processor's time stamp counter (TSC) after executing a loop repeatedly