If you need to remember one thing about authentication then you should remember that we never store passwords in plain text 🚫.

Because if any malicious person ever gets a copy of our database, they will have the email and password of all our different users. And this is a major issue because users tend to use the same email and password combination on several applications.

So the malicious person could potentially sign as another person not only in the app we manage but also in our users’ banking service app or their private gmail accounts.

And we don’t want to threaten the entire online presence of our people.

Hash functions

The goal of a hash function is to take some kind of input, calculate a hash based on that input and then return a digital fingerprint. With a hash function, the same input will always result in the exact same output, but if we make even a small change to the input, we are going to get back a completely different output.

And, very important, there is no way to take a hash and figure out what the original input was.

That’s why, during the sign up process, when the user inputs his password, we pass it through a hash function and we save the returned result into our database.

Image Source: freepik.com

Why hash functions are not enough

A rainbow table attack is a password cracking method that uses a “rainbow table” to crack the password hashes in a database (beyondidentity.com).

Some malicious person could get a list of the most popular passwords across the world, then run through this list of maybe hundreds or thousands or even million different passwords and calculate the hash of every one of them ahead of time.

Now, if this malicious person gets access to our database, they can analyze our hashed passwords and compare our stored hash passwords against all these precalculated hashes and find the passwords of our users.

To prevent this kind of attack we have to make our sign up and sign in process a little bit more complicated.

Hash and Salt

When the user inputs a new password, we will generate a random series of numbers and letters (salt). Then we take the user's password and salt and join them together in one single string and run our joined string into one hashing function.

Next we’re going to take that output and join it together with the original salt. We would usually put a period or some kind of a separate character between that output so we can tell which string is which or where one ends and the other begins. And this value is going to be stored inside our database (hash.salt).

Image Source: supertokens.com

So when a user signs in we find the user with what email, we separate password into salt and hash, we take salt and repeat the exact same process as we have done previously.

And we compare the hashed result. If it’s the same, than the user introduced the same password.

By adding on salt we transform the rainbow table attack into way too much work for a malicious user. To apply this technique would mean to regenerate the entire rainbow table with a different salt for every different possible salt in the word (billions of combinations).

So there is no way that anybody would ever want to make a such a big number of different rainbow tables that include every possible password out there with every possible salt combination.

This was hashing and salting! Until next time, stay safe and choose a strong password 💪.