[jira] [Comment Edited] (NIFI-4942) NiFi Toolkit - Allow migration of master key without previous password

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

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

Andy LoPresto edited comment on NIFI-4942 at 3/7/18 12:56 AM:
--------------------------------------------------------------

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


was (Author: alopresto):
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)