On 08/02/2018 11:17, Colm O hEigeartaigh wrote:
Hi Francesco,

On Wed, Feb 7, 2018 at 12:12 PM, Francesco Chicchiriccò <ilgro...@apache.org> 
wrote:

I see... what about wrapping SecureRandom in ThreadLocal instead, e.g. replacing
What does wrapping SecureRandom in ThreadLocal buy us from a performance POV?

As java.util.Radom's (since SecureRandom extends it) javadoc:

https://docs.oracle.com/javase/8/docs/api/java/util/Random.html

states,

"Instances of |java.util.Random| are threadsafe. However, the concurrent use of the same |java.util.Random| instance across threads may encounter contention and consequent poor performance.  Consider instead using ThreadLocalRandom in multithreaded designs."

Looking around the Internet, I've seen suggestions to either user ThreadLocalRandom or to wrap SecureRandom in Threadlocal to alleviate this issue.

Regards.

Also, we'll need to add to the reference guide the hint to set

-Djava.security.egd=file:/dev/./urandom

for Tomcat and other Java EE containers on Linux

Yes I think that's OK.

Colm.


WDYT?

On Mon, Feb 5, 2018 at 12:25 PM, Colm O hEigeartaigh <cohei...@apache.org>
wrote:

No, my query got passed on to someone else, still waiting to hear back....
Colm.

On Mon, Feb 5, 2018 at 7:44 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

Hi,
thanks for the feedback go to so far.

I know from IRC that Colm has been exploring the security feasibility
with some of his contacts:  any results so far?

Regards.


On 30/01/2018 08:24, Francesco Chicchiriccò wrote:

Hi there,
any feedback on this?
If no one sees issues with that I'll proceed as indicated.

Regards.

On 24/01/2018 17:54, Francesco Chicchiriccò wrote:

Hi all (and Colm in particular, as this should be in your chords),
we are currently basing all operations requiring random generation
(mainly tokens used during double opt-in and password reset, and
password
values for specific cases) on SecureRandom [1].

SecureRandom has, however, some performance issues which were solved,
starting with Java 7, by ThreadLocalRandom [2]; with Java 8 an
improvement
was made [3] to retain security by setting the system property
'java.util.secureRandomSeed' to true.

Shall we:

1. suggest to set

-Djava.security.egd=file:/dev/./urandom

for Tomcat and other Java EE containers on Linux, and

2. suggest to set

-Djava.util.secureRandomSeed=true

for Tomcat and other Java EE containers, and

3. replace SecureRandom with ThreadLocalRandom in [1]

?

Regards.

[1] https://github.com/apache/syncope/blob/2_0_X/common/lib/src/
main/java/org/apache/syncope/common/lib/SecureTextRandomPro
vider.java#L29
[2] https://docs.oracle.com/javase/7/docs/api/java/util/concurre
nt/ThreadLocalRandom.html
[3] https://docs.oracle.com/javase/8/docs/api/java/util/concurre
nt/ThreadLocalRandom.html

--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/




--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

Reply via email to