nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy LoPresto (JIRA)" <>
Subject [jira] [Commented] (NIFI-1240) SecureRandom is improperly seeded with current time
Date Thu, 03 Dec 2015 19:14:11 GMT


Andy LoPresto commented on NIFI-1240:

That is correct. We can use an unspecified algorithm for SecureRandom and allow the JRE to
decide based on the available CSPs. 

Thanks [~taftster], it is always nice to get another set of eyes on this stuff. 

> SecureRandom is improperly seeded with current time
> ---------------------------------------------------
>                 Key: NIFI-1240
>                 URL:
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 0.4.0
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>            Priority: Critical
>              Labels: easyfix, security
>             Fix For: 0.4.0
>         Attachments: 0001-NIFI-1240-removing-explicit-reference-to-SUN-provide.patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
> In, is used to generate a salt
for key derivation. However, the SecureRandom instance is seeded by System.getCurrentTimeInMillis(),
which is not random and is predictable. Instead, we should allow SecureRandom to seed itself
by calling SecureRandom.nextBytes(). 
> The instance accessor should also explicitly specify "SUN" as the cryptographic service
provider to avoid default CSP issues. 
> "First, while it is good that the code explicitly specifies the instance of SecureRandom
to be SHA1PRNG (because a call to .getInstance() will return whatever the Java properties
specify), to be completely explicit, it should be .getInstance("SHA1PRNG", "SUN") because
the Java cryptographic service provider (CSP) should be selected. On most systems this will
default to Sun, but it can conceivably cause issues if a different CSP is prioritized.
> Second, seeding the SecureRandom with the current time is most definitely not random
and is predictable. SecureRandom.nextBytes() actually self-seeds if the instance had not previously
been seeded, and this manual seeding is decreasing the entropy used. These two issues will
be resolved in an upcoming release, but are not related to the encryption issue we are addressing
> The fix is very simple. I have searched the project and this is the only use of SecureRandom
which is manually seeded. 

This message was sent by Atlassian JIRA

View raw message