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 each time 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.

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:

• 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

• 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.
• 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.
• Additionally, you can define the expiration date at a system level and for each token. If you need a script for a specific project that will end next week, you can make sure that the connectivity of the token will not outlive the project.

You can start using personal access tokens for Jira, Confluence and Bitbucket (both Server and Data Center) with a free trial.