vRO SecureString vs EncryptedString

One of my customers recently asked about the difference between a SecureString and an EncryptedString in vRealize Orchestrator. I've used SecureStrings many a time but not EncryptedStrings, so I set out to find an answer for myself and my customer.

I'm going to assume that I don't need to explain what a String is when used in reference to technology and programming in particular. The string data type is common across many programming and scripting languages and it's a type that vRealize Orchestrator (vRO) understands as well. So, what are SecureStrings and EncryptedStrings and what are the use cases and constraints for both.

SecureString

In vRO the SecureString type is almost identical to a String. The type definition in vRO's API Explorer is provided below:

When an attribute or variable is assigned the type 'SecureString' the value is no different to that of a String. The difference however is that a UI decorator is used to mask the value from prying eyes. As an example, this variable below:

SecureStrings are used in exactly the same way as normal strings. They can be manipulated like normal strings, passed to functions or methods and even converted to normal strings. As an example, I made a simple workflow that establishes an SSH connection to a test Linux server. Credentials etc. are stored as variables in the workflow as follows:

When executed, the workflow echos all the variables to the logs before establishing the SSH connection using an SSH Plugin method and executing the 'pwd' command.

Although I've blurred it in the image above, the password appears as plain text in the log output.

EncryptedString

Moving on to the EncryptedString type, let's look at the definition in vRO's API Explorer below:

It turns out that there's more going on here than the explanation above suggests. It terms of content it's still a string. The purpose of it is to contain a number of characters. But this is where the differences start to come in.

Encryption and Storage

As the name suggests, EncryptedStrings are encrypted! Before being stored in vRO's database the AES+CBC algorithm is used to encrypt the contents of the string. (You can read a bit about AES here on Wikipedia if you like.) An Initialization Vector (IV) is used as a key to encrypt and decrypt the data. This key is stored somewhere within vRO - don't ask me where.

Decryption

Like the SecureString the EncryptedString is shown as masked in the UI but that is literally just for show. If you try to edit the value you will just be faced with a blank field. Equally, the EncryptedString cannot be used in exactly the same way as the SecureString. I took my test workflow and changed the password to be stored as an EncryptedString. There's no need to blur the output at all here!

You might also notice that the workflow execution failed - the login was unsuccessful and the error message seems to show that the password variable contains NULL.

The two conclusions here are that:

1. An EncryptedString cannot be decrypted to plain text in a scripting block. (Which is good for security.)
2. Even though I passed the EncryptedString to a plugin method, it could not be decrypted there.

EncryptedString Use

If we look at the method that I attempted to use (connectWithPassword) the you can see that it expects a SecureString parameter:

Unlike with SecureStrings, where the value is the same it's just treatment in the UI that's different, there's no conversion of EncryptedString to SecureString going on.

At least not in this plugin (SSH)...

It's all about the plugin being used. To consume or use an EncryptedString you need a plugin that can accept that particular type. For example, the PowerShell plugin that comes natively with vRO.

The password attribute shown in the image above accepts an EncryptedString input. One thing I haven't been able to determine categorically however is whether EncryptedStrings work with the polyglot features of vRO. All of my testing was conducted with the native Javascript. I don't know for sure if PowerCLI, Python or NodeJS script blocks will work in the same way.

The primary use cases for an EncryptedString are evidently geared towards passwords and credentials but I will keep my eyes open to see if I can spot any others in some of the various plugin implementations.