Encrypting keys and passwords in scenarios

[david.w]

Passwords, tokens, app keys, etc really shouldn’t be placed as plain text in scenarios or variables within Make. When using HTTP modules with some API endpoints it might be necessary to include sensitive data in parameters or the request body.

For whatever the reason, it is pretty strange that Make doesn’t provide a more functional key vault. Ideally custom keys should be easy to create and use as needed in scenarios.

The technique I describe below makes things a bit more challenging for a bad actor, it isn’t an example of best practice. The goal here is to avoid storing keys in plain text on the system.

I’ll use AES encrypt / decrypt modules, a data structure, and data storage. This should also work with organisation variables when they can be created / updated from a scenario.



So here is the data structure:

The data store:

and a look (spoiler alert) at an encrypted password (you can create as many as needed):

This is the encryptor utility that inserts keys into data storage. Run once for each string you want to encrypt. It is recommended that you set this scenario to ‘Data is confidential’ mode after you finish testing and are ready to use it for real. Since you can’t delete scenario history, you might find ‘clone’ a great way to start with a clean slate (then delete the original). Don’t leave clear text passwords in your execution history.

key encryptor blueprint.json (10.4 KB)

And here is an example of how to use this in your scenario: Ideally you’ll also switch this to ‘Data is confidential’ and take the same precautions with the older execution history.

key decryptor blueprint.json (16.5 KB)

At the end of the day, this is only slightly better than nothing. Your treated strings are hidden from view when editing the scenario or data store and won’t be seen in an export of your blueprints. They can’t be easily viewed if someone has access to your account.

Of course, a bad actor with access to your account could use the same tools to execute the API or obtain clear text versions of your strings.

Make could help us not log sensitive data to the logs without hindering the debugging value of the logs by allowing the ‘Data is confidential’ setting to be used on a per-module basis.

Hope this helps someone - and I’m looking forward to the improvements the community will make to this.

[Michaela]

Heya @david.w

Thank you so much for taking the time to put together this detailed guide and for sharing it with the community! This is super valuable and we genuinely appreciate it

[Lior_Talmor_Guesty]

Hi @david.w !
I’m trying to use this but cannot fully understand how to configure the Encryptor fields…
I’ve created a key (which I think the module doesn’t really flow with) and tried a lot of combinations for all the other fields, + I’m not too sure how to handle the init_vector (Initialization Vector Encoding) part as well… Would you (or anyone else seeing this) perhaps be able (and kind enough) to provide more context on how to use this module?
Also, Make’s documentation for this module (https://www.make.com/en/help/app/encryptor) seems to be pretty lacking as well…

[Lior_Talmor_Guesty]

I ended up using the following script which produces two random strings:
One that you can put as the key value:

• Click ‘Add’ by the ‘key’ field
• Give it a name of your choice
• Put the first random key created by the script
• Choose Hexadecimal under the ‘Key Encoding’ field
  

Then at the bottom in the Initialization Vector, put the other random string created by the script.
And there you have it! You can now use the guide as intended
Here’s the script (Just run it somewhere that supports Javascript / Node.js):

const crypto = require('crypto');

const key = crypto.randomBytes(32).toString('hex'); // 256-bit key

const iv = crypto.randomBytes(16).toString('hex'); // 128-bit IV

console.log(key);

console.log(iv);

Enjoy the newly gained credentials freedom