[ 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 <ald...@apache.org> > 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)