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.