[
https://issues.apache.org/jira/browse/NIFI-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036965#comment-15036965
]
ASF subversion and git services commented on NIFI-1240:
-------------------------------------------------------
Commit bde270a9118a00ecd3ee476dc1314a7fc3240a74 in nifi's branch
refs/heads/master from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=bde270a ]
NIFI-1240:
Added explicit reference to Sun Java Cryptographic Service Provider in
PasswordBasedEncryptor.
Removed manual seeding of SecureRandom in PasswordBasedEncryptor.
This closes #138.
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
>
> 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)
