You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2018/01/24 16:54:00 UTC
[PROPOSAL] Replace SecureRandom with ThreadLocalRandom
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/
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Andrea Patricelli <an...@apache.org>.
Hi all,
for me definitely +1.
Best regards,
Andrea
Il 24/01/2018 17:54, Francesco Chicchiriccò ha scritto:
> 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
>
--
Dott. Andrea Patricelli
Tel. +39 3204524292
Developer @ Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
Apache Syncope PMC Member
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò
>> <il...@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 <
>>>>> coheigea@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ò <
>>>>>>> ilgrosso@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/
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 08/02/2018 11:37, Colm O hEigeartaigh wrote:
> On Thu, Feb 8, 2018 at 10:29 AM, Francesco Chicchiriccò <il...@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.
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 <
>>>> coheigea@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ò <
>>>>>> ilgrosso@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/
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Colm O hEigeartaigh <co...@apache.org>.
On Thu, Feb 8, 2018 at 10:29 AM, Francesco Chicchiriccò <ilgrosso@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)?
Colm.
>
> 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 <
>>> coheigea@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ò <
>>>>> ilgrosso@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/
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 08/02/2018 11:17, Colm O hEigeartaigh wrote:
> Hi Francesco,
>
> On Wed, Feb 7, 2018 at 12:12 PM, Francesco Chicchiriccò <il...@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 <co...@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ò <
>>>> ilgrosso@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/
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
On Wed, Feb 7, 2018 at 12:12 PM, Francesco Chicchiriccò <ilgrosso@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?
> 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 <co...@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ò <
>>> ilgrosso@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/
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 07/02/2018 13:02, Colm O hEigeartaigh wrote:
> Hi Francesco,
>
> The feedback I have got is that the algorithm used in ThreadLocalRandom is
> not secure enough to be considered a SecureRandom. So I think it's probably
> not OK to switch if we are using it to generate tokens unfortunately.
I see... what about wrapping SecureRandom in ThreadLocal instead, e.g.
replacing
private static final SecureRandom RANDOM = new SecureRandom();
with
private static final ThreadLocal<SecureRandom> RANDOM = new
ThreadLocal<SecureRandom>() {
@Override
protected SecureRandom initialValue() {
return new SecureRandom();
}
};
in
https://github.com/apache/syncope/blob/2_0_X/common/lib/src/main/java/org/apache/syncope/common/lib/SecureTextRandomProvider.java
?
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
WDYT?
> On Mon, Feb 5, 2018 at 12:25 PM, Colm O hEigeartaigh <co...@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ò <
>> ilgrosso@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/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/
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
The feedback I have got is that the algorithm used in ThreadLocalRandom is
not secure enough to be considered a SecureRandom. So I think it's probably
not OK to switch if we are using it to generate tokens unfortunately.
Colm.
On Mon, Feb 5, 2018 at 12:25 PM, Colm O hEigeartaigh <co...@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ò <
> ilgrosso@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/SecureTextRandomProv
>>>> ider.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/
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Colm O hEigeartaigh <co...@apache.org>.
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ò <il...@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/
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/
Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom
Posted by Matteo Alessandroni <ma...@tirasa.net>.
Hi,
+1 for me.
Best regards,
Matteo
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
>
--
Dott. Matteo Alessandroni
Software Engineer @ Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
Tirasa S.r.l. <http://www.tirasa.net>