[jira] [Reopened] (NIFI-1257) Provide additional KDFs for EncryptContent

["Andy LoPresto (JIRA)" <ji...@apache.org>]

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

Andy LoPresto reopened NIFI-1257:
---------------------------------

There is an incompatibility between the new implementation of NiFi legacy KDF because the original code determined the salt size based on the cipher block size but did not encode this variable length into the cipher stream. I am patching the new implementation with additional logic to determine the legacy salt size based on cipher selection. 

> Provide additional KDFs for EncryptContent
> ------------------------------------------
>
>                 Key: NIFI-1257
>                 URL: https://issues.apache.org/jira/browse/NIFI-1257
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core Framework
>    Affects Versions: 0.4.0
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>            Priority: Critical
>              Labels: encryption, security
>             Fix For: 0.5.0
>
>
> Currently, the two key derivation functions (KDF) supported are NiFi Legacy (1000 iterations of MD5 digest over a password and optional salt) and OpenSSL PKCS#5 v1.5 (a single iteration of MD5 digest over a password and optional salt). 
> Both of these are very weak -- they use a deprecated cryptographic hash function (CHF) with known weakness and susceptibility to collisions (with demonstrated attacks) and a non-configurable and tightly coupled iteration count to derive the key and IV. 
> Current best practice KDFs (with work factor recommendations) are as follows:
> * PBKDF2 with variable hash function (SHA1, SHA256, SHA384, SHA512, or ideally HMAC variants of these functions) and variable iteration count (in the 10k - 1M range). 
> * bcrypt with work factor of 12 - 16
> * scrypt with work factor of (2^14 - 2^20, 8, 1)
> The salt and iteration count should be stored alongside the hashed record (bcrypt handles this natively). 
> Notes:
> * http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/
> * http://blog.ircmaxell.com/2012/12/seven-ways-to-screw-up-bcrypt.html
> * http://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt
> * http://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256/3993#3993
> * http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415 
> * http://web.archive.org/web/20130407190430/http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
> * https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/march/enough-with-the-salts-updates-on-secure-password-schemes/
> * http://www.tarsnap.com/scrypt.html
> * http://www.tarsnap.com/scrypt/scrypt.pdf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)