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/SecureTextRandomProvider.java#L29 [2] https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadLocalRandom.html [3] https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/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/

Reply via email to