3DES Password Based Encryption with vRealize Orchestrator (vRO/vCO)


A requirement that often arises in large, complex orchestration projects is the need to encrypt and decrypt information. One such requirement recently specified triple DES password based encryption as the standard, which led me through a lot of Google searches to CryptoJS.

CryptoJS is a growing collection of standard and secure cryptographic algorithms implemented in JavaScript using best practices and patterns. They are fast, and they have a consistent and simple interface.

Importantly for me, the collection includes a 3DES library. Unfortunately, this is where I stalled for a long time - I could not manage to get the CryptoJS library to work, and it became clear that it was likely to be beyond my skill set. Falling back on Google with a vengeance, I found this VMware Communities post - CryptoJS Hashers and Cyphers, and in it a package created by Dan Linsley (@danlinsley) which contained an encrypt and decrypt action for 3DES, based on CryptoJS. The package also contains actions for generating random initialisation vectors and base64 encoding. In short, exactly what I needed!

Based on this excellent work, I created two workflows, Encrypt-3DESPassword and Decrypt-3DESPassword.

Encrypt-3DESPassword

Inputs

  • password - the password that will be encrypted (SecureString)
  • encryptionPassphrase - a passphrase that will be used to encrypt and decrypt the password (SecureString)

The use of the SecureString type means that it won’t be displayed in the GUI of vRO/vCO - it’s a very slight improvement in security, and can be used anywhere a String would be.

Outputs

  • encryptedPassword - the encrypted password (SecureString)
  • initialisationVector - the initialisation vector used in the encryption (SecureString)

The use of the SecureString type means that it won’t be displayed in the GUI of vRO/vCO - it’s a very slight improvement in security, and can be used anywhere a String would be.

Attributes

  • generatedInitialisationVector - variable to hold the randomly generated IV (SecureString)
  • base64Key - variable to hold the encryptionPassphrase converted to a base64 key

Schema

The schema is very linear, consisting of 3 actions from Dan’s library, and a script block.

  • generateRandomIV takes no inputs and spits out a random initialisation vector to the generatedInitialisationVector attribute
  • sha256HashBase64 takes the encryptionPassphrase input parameter and outputs a base64 encoded key, which is assigned to the base64Key attribute
  • tripleDesEncrypt takes the password input parameter, the base64Key attribute and the generatedInitialisationVector attribute and returns the encrypted password to the encryptedPassword out parameter
  • outParam simply takes the generatedInitialisationVector attribute and assigns it to the initialisationVector output parameter

Sample Execution

These are not designed to be used by an operator, but consumed as part of another workflow - as such there’s no output that is human readable - to show the values generated I have to wrap them within another workflow and use System.log() to print the values.

The wrapper workflow simply calls the Encrypt-3DESPassword workflow and then prints the outputs:

Which when run looks like this - note that nothing is visible in plain text, except the encryptedPassword and initialisationVector we deliberately wrote to the log.

Decrypt-3DESPassword

Inputs

  • encryptedPassword - the encrypted password (SecureString)
  • decryptionPassphrase - the passphrase used to encrypt the password (SecureString)
  • initialisationVector - the initialisation vector used to encrypt the password (SecureString)

Outputs

  • decryptedPassword - the decrypted password (SecureString)

Attributes

None

Schema

The schema couldn’t be simpler - the one action is the decrypt action.

  • tripleDesDecrypt takes the encryptedPassword, decryptionPassphrase and initialisationVector input parameters and sets the decryptedPassword output parameter

Sample Execution

Once again, these are not designed to be used by an operator, but consumed as part of another workflow - as such there’s no output that is human readable - to demonstrate I’ve written a workflow that encrypts, then decrypts the values.

  • logInputs - writes the password and passphrase to the system log
  • Encrypt-3DESPassword - does as specified above
  • logOutputs - writes the encrypted password and the initialisation vector to the system log
  • Decrypt-3DESPassword - does as specified above
  • logOutputs - writes the decrypted password to the system log

No variables are human readable

Notes for using these workflows

The initialisation vector is generated randomly each time to minimise the possibility of an inference attack. If you use the same IV and a hacker is able to obtain enough encrypted passwords and the IV, then blocks could be inferred and the passwords decrypted (this is how WEP encryption is typically broken).

Storing the encrypted password, IV and pass phrase in the same location would render the encryption pointless, so think carefully about what you store where.

Finally, use this at your own risk - I do not offer any guarantee or hold any responsibility if it pickles your grandmother.

Download

You can download the CryptoJS package from CryptoJS Hashers and Cyphers.

You can download my workflows from here: local.definit.passwords.package (zip)

Share this post