Password Handling Tier List: Worst to Best

If you're a web developer, you most probably had to manage user’s password. There are a lot of good, bad & ugly ways to handle passwords in your system.
Today , I will share with you a tier list of handling password in your application.
I will go from the worst, to the best. And explain the reasoning behind them.

𝐅 𝐓𝐢𝐞𝐫: 𝐩𝐚𝐬𝐬𝐰𝐨𝐫𝐝 𝐢𝐧 𝐩𝐥𝐚𝐢𝐧𝐭𝐞𝐱𝐭

Let’s start at the bottom. And I mean ,the absolute rock bottom.

You are storing the password in plaintext. This is the worst.

Because, when the database is compromised - any hacker or a system admin- can get full access to all confidential user credentials. No need to crack or decrypt- or do anything . Full instant access.

It is trivial for anyone with access to the database, to impersonate or take over the account of all the users.
You are giving away all the keys to the kingdom.

Surely we can do better

C 𝐓𝐢𝐞𝐫: 𝐇𝐚𝐬𝐡𝐢𝐧𝐠

Way better than storing the password the plaintext , is when you hash the password and store the hash.

Even when the database is compromised- hacker or system admin can not get direct access to confidential user passwords. Instead they get the hashes.

Okay, so why is this an improvement? And how does hashing really help here?

Hashing creates a fixed-length output digest from any amount of input data - it's one-way and irreversible. Even a tiny change gives a completely different hash.

For example this is the sha-256 hash of ‘Not so secret password‘ & ‘Not so secret Password‘ (‘P‘ is capitalized).

See a tiny change in input completely changes the output . So hashing is like a fingerprint for your data.

Understand that, for building login authentication systems- you only need to compare passwords, not retrieve them. And comparing fingerprints of two passwords is just as effective as comparing two passwords for authentication purpose.

That way our application can check if the hash of your newly entered password matches with your existing hash in the database, without having the liability of storing your actual password.

So, there is no way for the attacker to have your password directly in this case.

But, hold up. it’s not bulletproof either.

If the hacker gets access to the database- they can still run rainbow table attacks.

So, what is a rainbow table?

That’s basically a cheat sheet full of common passwords and their matching hashes.

Most people use extremely common and predictable passwords. Here are some common passwords and their md5 hash for example.

Hackers can just look up in a rainbow table in O(1) time , to find password of the relevant hash.
And it is common to find up to 95% of leaked database’s password hashes available in rainbow tables .
Let that sync in.

𝐁 𝐓𝐢𝐞𝐫: 𝐒𝐚𝐥𝐭 & 𝐇𝐚𝐬𝐡𝐢𝐧𝐠

Rainbow tables only work because each password is hashed the exact same way.
So if two people use the same password?
Boom, same hash.

So the more common the hash across the users, the more common the password .

That’s a problem.

Because now hackers can just pre-compute a giant list of common passwords and their hashes (aka rainbow tables), and use it like a cheat sheet.

But here’s the trick: we mess with their cheat sheet.

How?

We add a little secret ingredient to each password before hashing it. A random string. A salt.

So instead of doing Hash(Password), we do Hash(Password+Salt) .

So, same password will result in drastically different hashes, because of the unique salts being added.

An attacker won't know in advance what the salt will be, so they can't pre-compute a lookup table or rainbow table. If each user's password is hashed with a different salt, the reverse lookup table attack won't work .

So , this defeats rainbow table attacks .

𝐀 𝐓𝐢𝐞𝐫: 𝐒𝐚𝐥𝐭 & 𝐒𝐥𝐨𝐰 𝐇𝐚𝐬𝐡𝐢𝐧𝐠

Salt prevents rainbow table attacks by making each hash unique. But, hackers have GPUs & custom hardware . Big & fast ones. They can brute-force & crunch billions of hashes per second.

Salting isn’t enough for tackling this. The attacker can still go brute-force dictionary attack mode with their hardware .

How to stop that ?

What if... we take that same Hash(password + salt) thing... ...but do it again . And again . Like 1,000 times or 10,000 times or 1,00,000 times.

This is called ‘Key Stretching‘ or ‘Slow Hashing‘

But, why do we do this?

Because if it’s slow for you- it’s torture for the hackers. As it will be significantly slower for an attacker to generate a rainbow table for a given salt.

Best practice is to make it take about 1 second per password hash.

Why?

Because, in this way it is still fast enough to not cause a noticeable delay for the user. But, really slow for an attacker trying to do this a billion times.

We want to make the life of an attacker very very hard

So, here is the tier list, of handling password securely- as a visual summary

/

/