No-code platforms need to impersonate users to create automations and integrations. Unfortunately, accessing your password means they can’t do a very good job at hiding it.
I used to underestimate the security risks of using external platforms that authenticate to an API on your behalf using your credentials.
After all, if that’s their business, they surely do a good job at protecting the passwords and they will do to any length to follow industry standards.
Well, it happens to be the case that the industry standard for storing passwords is to hash them and salt them.
The problem is precisely that no-code platforms can’t do that, even if they wanted.
Let me explain you why Zapier, for example, doesn’t hash your password.
Watch the video if you’re in a hurry:
When an application stores a user password in a database, it hashes it, then stores the resulting hash code. The password is visible in the web server, but it never enters the database server.
When a user authenticates again, the application doesn’t use the literal password. Instead, it takes the password through the same hashing process, then compares the result to what’s stored in your database for that user:
No-code platforms can’t follow this process, because they want to access an API on behalf of a user.
What does this mean? That they need to use your password as if they were you. And you don’t use a hash, do you? You don’t even see it.
If Zapier hashed the password and stored the result, they wouldn’t be able to access the password again when it’s needed.
What they do is either
There are different options to secure API calls through basic auth. The most interesting is to use API Tokens, also called personal access tokens or API keys.
Have a look at the alternatives to personal access tokens here
You can think of personal access tokens as the middle ground between a password and a hash: