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/
