4. Password hashing

Passwords

wikipedia login page
Wikipedia's login screen

In the early 1990s, Internet started taking off, lots of companies started launching their products on the World Wide Web. People started signing up on these new platforms with their username and password.

hacked db illustration
A compromised database

In those days, database breaches via SQL injection attacks were common, it often revealed users' usernames and passwords to the hacker.

And if a user's username and password is revealed then there's a great chance that the user had used the same username and password for other sites, so, basically the hacker got access to users' multiple accounts. This was an extremely serious concern.

How can we not reveal a user's password to the hacker even if he has unauthorized access to the database? Any guesses?

Not revealing the password

Here's the problem that we are going to brainstorm on --

We have learned about symmetric key encryption. It's a great way to hide information. So, what if we, take the user's password, encrypt it using a secure encryption algorithm and store the encrypted value (ciphertext) on the database not the user's actual password.

When user needs to login, they enter their password, we'll encrypt it again with the same algorithm and the same key. So, if the user entered the same password as he had set, the encrypted value will come out same as before and login will be successful.

Our stated problem is solved! We are not revealing the user's password. Login is working fine as well. Anything wrong with the above approach? 🤔

If you look closely, we will need to store the encryption key because without the key we won't be able to carry out the encryption process during future logins to check if the password is correct.

We will store the key in may be a different database, right? Now, this new database full of user passwords' encryption keys is the only thing a competent hacker needs access to and all of the users' account will be in his control!

We cannot assume that the attacker won't ever be able to breach our database containing encryption keys. We want to solve the problem that even if the database gets breached, we don't want the attacker get access to the passwords. But in this case, if the attacker is successful in breaching the database containing encryption keys, he will be able to decrypt all user passwords. Once the passwords are decrypted, they will get revealed in their original cleartext form!

Now you see, why encryption is not the right solution. Pause a bit and think if you have any other ideas to solve this?

Hash the passwords!

password hashing in the db illustration
Attacker unable to access cleartext passwords because of hash

We have learned that hashing is a one-way function. Once we hash an input, we cannot derive the input from the hash value. So when the user creates an account, we hash the user's password and store the hash on the database.

password hashing illustration
Password hashing process during account creation and then subsequent authentication. Click to zoom.

Now, when the user will request to login in future, we will hash the entered password, if the output hash comes to out be same as the hash we stored during account creation, it'll mean that the user entered the correct password.

Even if our database is compromised, the hacker won't be able to figure out the actual password. You know why, right? Because hashing is a one-way function so hacker cannot take the hash and convert it to the actual password.

Hashing the password doesn't reveal the user's password and login works out well. We have finally solved our quest!

Umm, the bad guys keep on growing their arsenal, they have some plans to attack us, let's face them in the next lesson!

Go to next lesson: Rainbow table and the salt