[
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)
