On 08/02/2018 11:38, Francesco Chicchiriccò wrote:
On 08/02/2018 11:37, Colm O hEigeartaigh wrote:
On Thu, Feb 8, 2018 at 10:29 AM, Francesco Chicchiriccò <ilgro...@apache.org> wrote:
"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.
I'm just wondering if it could actually lead to worse performance if we
have multiple wrapped SecureRandom instances blocking on /dev/random
(without setting it to /dev/urandom)?

That's why I would also add to the guide such setting.

Done: https://git-wip-us.apache.org/repos/asf?p=syncope.git;a=commit;h=e3505eb4d214815f87fb2556233541406ecb9b4a

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/

Reply via email to