[ 
https://issues.apache.org/jira/browse/NIFI-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16388795#comment-16388795
 ] 

Andy LoPresto commented on NIFI-4942:
-------------------------------------

The proposed mechanism for this is to store the current password in a 
cryptographically hashed format locally and allow the toolkit to accept that as 
a parameter in place of the plaintext existing password or key during 
migration. This enables the sensitive material to be stored in a format that is 
not vulnerable to reversing but still requires a user to prove knowledge 
of/access to the original password in order to perform a migration. 

Current example usage:

{{$ ./bin/encrypt-config.sh -m -w existingPassword -p thisIsTheNewPassword ...}}

The above will still be supported (along with {{-e}} and {{-k}} options for 
existing and new key (hex) respectively). However, another mode will be 
supported:

{{$ ./bin/encrypt-config.sh -m -z secure_hash(existingPassword) -p 
thisIsTheNewPassword ...}}

where the {{-z}}/{{--secure-hash}} argument specifies that the following 
argument is the secure hash of the existing password, using the algorithm:

{{secure_hash = bcrypt(version, workFactor, salt, existingPassword)}}

and the following values:

* {{version}} = {{2a}}
* {{workFactor}} = {{12}} (actually log~2~ value, so 2^12^ iterations)
* {{salt}} = {{ABCDEFGHIJKLMNOPQRSTUV}} a randomly-generated, 22 character 
Base64-encoded unpadded salt value. This decodes to 16 bytes when used in the 
derivation process
* {{existingPassword}} = the current (pre-migration) password used to derive 
the key which is currently encrypting the sensitive properties

In the event the user had been using raw keys rather than passwords (which is 
not the case for Ambari, but will be provided for completeness), a similar 
process can be used with the {{-y}}/{{--secure-hash-key}} arguments:

{{$ ./bin/encrypt-config.sh -m -y secure_hash_key(existingKeyHex) -p 
thisIsTheNewPassword ...}}

where the {{-y}}/{{--secure-hash-key}} argument specifies that the following 
argument is the secure hash of the existing key in hexadecimal encoding, using 
the algorithm:

{{secure_hash_key = bcrypt(version, workFactor, salt, 
lowercase(existingKeyHex))}}

and the following values:

* {{version}} = {{2a}}
* {{workFactor}} = {{12}} (actually log~2~ value, so 2^12^ iterations)
* {{salt}} = {{ABCDEFGHIJKLMNOPQRSTUV}} a randomly-generated, 22 character 
Base64-encoded unpadded salt value. This decodes to 16 bytes when used in the 
derivation process
* {{existingKeyHex}} = the current (pre-migration) key in hexadecimal encoding 
which is currently encrypting the sensitive properties. This value will be 
lowercased before being fed to the {{bcrypt}} function to ensure that case 
sensitivity does not matter

> NiFi Toolkit - Allow migration of master key without previous password
> ----------------------------------------------------------------------
>
>                 Key: NIFI-4942
>                 URL: https://issues.apache.org/jira/browse/NIFI-4942
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Tools and Build
>    Affects Versions: 1.5.0
>            Reporter: Yolanda M. Davis
>            Assignee: Andy LoPresto
>            Priority: Major
>
> Currently the encryption cli in nifi toolkit requires that, in order to 
> migrate from one master key to the next, the previous master key or password 
> should be provided. In cases where the provisioning tool doesn't have the 
> previous value available this becomes challenging to provide and may be prone 
> to error. In speaking with [~alopresto] we can allow toolkit to support a 
> mode of execution such that the master key can be updated without requiring 
> the previous password. Also documentation around it's usage should be updated 
> to be clear in describing the purpose and the type of environment where this 
> command should be used (admin only access etc).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to