😔 Revealed passwords

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 don't want to store the user's actual password on the database (referred to as cleartext or plaintext password). So that even if the hacker has unauthorized access to the database, he can't access the user's passwords.
For login to work, there must be a way through which we can make sure that the user entered the correct password.

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.

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!

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 if we hash the users' password and store the hash on the database, then even if our database is compromised, the hacker won't be able to figure out the actual password. He will just see the hashes.

password hashing illustration — Password hashing process during account creation and then subsequent authentication

Now, when the user requests to login, we can hash their entered password, if the output hash comes to out be same as the stored hash, it means the user has entered the correct password.

Hashing the password doesn't reveal the user's password and login works out well. And the hacker cannot figure out the passwords from the hashes. Remember, hashing is a one-way function? ;) 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!

🧐 Please, fill a short feedback form. Worked hard on all of this, can't wait to listen your honest feedback!