You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nifi.apache.org by "Aldrin Piri (JIRA)" <ji...@apache.org> on 2015/12/03 01:47:10 UTC

[jira] [Resolved] (NIFI-1240) SecureRandom is improperly seeded with current time

     [ https://issues.apache.org/jira/browse/NIFI-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aldrin Piri resolved NIFI-1240.
-------------------------------
    Resolution: Fixed

> SecureRandom is improperly seeded with current time
> ---------------------------------------------------
>
>                 Key: NIFI-1240
>                 URL: https://issues.apache.org/jira/browse/NIFI-1240
>             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
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In PasswordBasedEncryptor.java, java.security.SecureRandom 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 now."
> 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
(v6.3.4#6332)