Why No-Code Platforms Can't Hash Your Password
Updated: Sep 7
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:
How hashing passwords works:
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:
If there's a match, then the login succeeds and the user is authenticated.
If there's no match, then the user will be shown a login error
Why can't no-code platforms do this?
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
store the password in clear text
encode it so that they can later decode it. Then everytime it has to be used, the code is reversed and the password is used for authentication.
How can no-code platforms access APIs securely?
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.
You can think of personal access tokens as the middle ground between a password and a hash:
They replace passwords
They're checked by the API resource to match the token stored in the database for that user
They can't be used by a user to log into the application
The benefits of API Tokens are multiple:
Compromised API Tokens don't propagate. Since each token is used for a specific connection, an attacker cannot use it for other connections or applications.
You can set up permissions. For example, you could permit your developers to create tokens, but force business users to ask for a token to an administrator.
Sometimes personal access tokens can also be scoped. This means that you could for example create a token that only allows reading information from the database. If this token is compromised, an attacker won't be able to mess with your data.