Introduction to API Authentication

Why it's important to always hash your passwords

In this article we'll talk about API authentication and why it's important to hash a password before saving it to a database.

As you know, if we stored plain text passwords in a database they would be available for anyone to see and use for all sorts of nefarious purposes.

It's very important, from a security standpoint, that all passwords stored in a database be encrypted in a way that makes them difficult or nearly impossible to guess.

Usually, this is achieved by sending the password string entered by a user during registration through an algorithm that generates a hash from the password.
A hash is a seemingly random combination of letters and numbers that is considered hard to decrypt by a potential attacker.

We can see an example of how hashing works using an online tool like Passwords Generator .
If we enter a password in this tool, it generates a hash using the SHA256 algorithm and shows what the hashed string would look like.

For example, if we enter the string "password" we would get this hash:


If we enter the string "password1", even though we are adding only one extra character we would get a totally different hash:


No matter how long our input string is, we always get a hash of the same length, that always corresponds to the entered password.

Hashes by themselves are not that secure, though

At first sight, it may seem that hashing a string is a very secure way to encrypt a password, but this is not always true.

Of course, hashing is better than using a plain text string.
But the problem is that since any particular string, no matter how complex or long it is, always generates the same exact hash, hackers have over time compiled tables of hashes and their corresponding un-hashed strings, called rainbow tables.

When hackers get access to a hashed password, they look up the hash in the rainbow table and often they are able to find the corresponding plain text string.

We can test this out by ourselves with a tool like CrackStation .

If we enter the hash of "password1" that we have encrypted above, Crack Station easily finds out that not only it corresponds to the string "password1", but also the type of hash we have used (SHA256).

Even if I am using the hash of a less obvious password, like "redturtles", it still gets found out immediately by Crack Station.

Enter salts

One way to sidestep this problem is to use what is called a "salt" when hashing a password.

A salt is a string known only to the server that introduces an element of randomness to the password hashing mechanism.

When the server encrypts a password with a tool like bcrypt, it adds a "salt" to the hashed password, and re-hashes the resulting string several more times.

This generates a more random and secure hash in the end, that hopefully is very hard for hackers to decrypt.

We'll stop here for now. In future articles we'll show how to create an authentication system that uses the bcrypt library to hash passwords.

Did you like this article? Share it with your friends.
I write daily about front-end and back-end web technologies.
You can receive all my articles in your inbox by subscribing to my newsletter. Just click the button below. No spam, just good, useful content. Guaranteed!

Follow me on Twitter