Cryptographic Hashing Functions and Password Salts.

Photo by Author via Canva

In this article, we will be exploring what cryptographic hashing functions are and how they’re beneficial for us in the authentication process of our apps. But before we discuss fancier terminology, it’s important to have a clear understanding of what authentication means in an application. Authentication is a term that’s often been confused with authorization. So let’s see what they mean and how they differ from each other.

Authentication vs Authorization.

Authentication is the process of verifying whether an individual is the same person he claims he is when trying to log into an application. This is what we normally do when we provide our username and password to a system. It verifies whether our credentials are correct and if and only if they’re valid, we can log into the system.

Username and password are the most common ways of authenticating a user but in applications that need extra security, there can be many more ways of user authentication in the form of security questions, facial recognition, etc.

Authorization comes after authentication. Meaning, after a user is logged into the system, we don’t want that particular user to mess with every single resource of our application.

We should be more granular about what our users can do and cannot do within the application scope. Think of it like this, if you log into Instagram, you can delete or edit your posts. But you’re not authorized to do the same for someone else’s posts just because you’re logged in. That’s the idea behind authorization.

So in essence, authentication comes first. It’s the first barrier to overcome when getting what we want out of a system. Then once we’re warmly welcomed into the system, then authorization takes it from there. It determines what we can do and what we cannot do ultimately in terms of privileges.

Unwritten Rules of Authentication.

As discussed, typically we use username and password for registering verifying users in our applications. But did you ever give a thought about what’s happening behind the scenes when we register a new user? How is this data being stored in databases? User credentials are sensitive data and we cannot just insert them into our databases in the way we would for other information.

Well, the first rule to remember is, we NEVER save passwords as it is in the database. Saving passwords as texts in our database associated with the user is undoubtedly a recipe for disaster.

The main reason not to do so is that, if someone else got hold of your database, then you’re absolutely screwed. Not to mention the fact that the vast majority of users tend to reuse passwords from one application to another.

So, if you store passwords in text format in your database, and someone got access to your database, there is a potential risk of cracking into other applications with these credentials. So do not ever take this approach of saving passwords in the applications you’re building.

So now the big question is, how do we store passwords? Well, that’s where hashing comes to play. Instead of storing passwords as they are, we should hash our user’s passwords and then store the hashed version of them in our storage.

Hashing Functions.

As shown in the above diagram, hashing functions take an arbitrary-sized normal textual password and then spit out a hashed version of it. The hashed version consists of a bunch of weird-looking non-related characters.

One special thing about hashing functions is, they are one-way functions. That means you cannot reverse the procedure and get the text password from hashed password.

There’s also no relationship whatsoever between characters in our normal passwords and characters in hashed one. Hashed passwords are fixed in size which means they will be of the same size no matter how long our original password is. All these features make it hard to get an idea of our original password by analyzing the hashed version.

It is this hashed version of the user’s password that we store in the database along with the username.

When a user tries to log in with their credentials, the provided password is hashed and compared with the existing password in the database. If it’s a match for the specific username, then the user is successfully logged in whereas if they didn’t match then it’s an unsuccessful attempt.

Hashing function always spits the same encrypted version for a given word. If not it won’t be that much of use since we cannot do the validation afterward.

Cryptographic Hashing Functions.

A cryptographic hash function is a mathematical algorithm that maps data of arbitrary size to a bit array of a fixed size.

There are many different hash functions but ones that are dealing with credentials have few properties in common. These are all there in place to make password cracking difficult.

1.Non-reversible, one-way functions.

This means, hash functions dealing with credential encryption, should make it very hard to reconstruct the original password from the hashed version. This is very important because if someone gets access to the database storing the hashed passwords, they shouldn’t be able to figure out what the original passwords are.

2. Non-predictable.

Simply put, no one should be able to guess the password from analyzing the hash of it.

3. Should have an avalanche effect.

The ‘Avalanche effect’ ensures that there’s a massive change in the hash if a single character of the original password is changed. Should you get a certain hash for a password, and then in the event of changing a single character of it, the resultant hash should be completely different. This makes it difficult to trace passwords with a lot of similarities which is one of the primary steps of cracking passwords.

4. Determinism.

This drill-downs to the fact that for the same password, always the hash should be the same. This enables cross-validations that are done when authenticating a user.

5. Collision resistance.

This means it’s very very very unlikely to have two different passwords which are enciphered to the same hash. This is one of the rarest things to happen if it does.

Password Salting/ Hash Salts.

This can be considered as an extra safety measure that we take in order to make reverse-engineering of passwords even harder.

The first thing to know is many people reuse their passwords across different sites. They may have the same password for Facebook, Instagram, etc.

Secondly the fact that there are unbelievably huge amounts of people who uses the same password. Meaning there are records of top passwords used by people across the world. Here are the top 5 according to Wikipedia for the year 2019.

1. 123456
2. 123456789
3. qwerty
4. password
5. 1234567

There are a lot of common passwords that are being used by millions of people. As Wikipedia states 25 most commonly used password lists contain more than 10% of the surveyed passwords and “123456” alone makes up 4% of it.

Thirdly, Among the few hash functions for passwords, bcrypt is the vastly used one and the most famous.

Now think about these 3 facts from a hacker’s point of view. A lot of people reuses passwords across sites, there are a lot of common passwords, the hashing function used to encrypt them is also not a secret and is well-known.

This can be a disaster. Let me explain why. If a hacker breaches into the environment, they would know we use bcrypt by looking at the enciphered password codes in our database. That’s easy to tell and takes no brainer because as I mentioned bcrypt is one of the handfuls of options we have.

He would also know a list of common passwords to test against, and if one attempt becomes successful he would know the textual password of a hashed password by reverse-engineering it.

Then instantly, he would know the password for everyone else with the same hash, if there’s any(There’s a high possibility of this because he cracked a common password).

This is just one scenario where things can go wrong. And I’m pretty sure there can be a lot of ways it can.

So how do we solve this issue? Well, that’s what password salts are all about.

A salt is a random string added to the password before it goes through the hash function to ensure its uniqueness.

So after salting, even for the same passwords, an entirely different hash will be stored in the database, and therefore even if one password is breached, the other accounts having the same password will remain safe.

Then the salt is stored alongside the password hash to make cross-validations possible when authenticating.

Hope you enjoyed reading this article! Until next time!