[
https://issues.apache.org/jira/browse/NIFI-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15038465#comment-15038465
]
ASF subversion and git services commented on NIFI-1240:
-------------------------------------------------------
Commit 3656c883c7ed35f0dcda73ebb89ee83b0bc2f1b1 in nifi's branch
refs/heads/master from [~joewitt]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=3656c88 ]
NIFI-1240 removing explicit reference to SUN provider. Not necessary for our
use and ties us to Sun or JREs with Sun JCE available. Favoring no-args
constructor instantiation of SecureRandom for greater flexibility in choosing
from available CSPs. Deprecating the associated public constant for the PRNG.
Signed-off-by: Aldrin Piri <[email protected]>
> 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
>
> Attachments:
> 0001-NIFI-1240-removing-explicit-reference-to-SUN-provide.patch
>
> 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)
