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.
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.
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.
The schema is very linear, consisting of 3 actions from Dan’s library, and a script block.
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.
None
The schema couldn’t be simpler - the one action is the decrypt action.
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.
No variables are human readable
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.
You can download the CryptoJS package from CryptoJS Hashers and Cyphers.
You can download my workflows from here: local.definit.passwords.package (zip)