So let's think about storing the users' passwords in the backend database.

You can store it:

• in plain text (a really bad idea...)
• hashed (better)
• salted and hashed (much better!)

​

Let's think about these options...

​

The plain text can be read by developers and admins 🥴, but in case of a database breach... that's a birthday gift 🎀 for hackers! If they get access to the users' records, they don't have to do anything more. GAME OVER for users.

​

A much better (and usually used) option is to hash the password. Many different cryptographic algorithms generate a fixed-length digest (hash) for variable input data.

​

Hashing algorithms are used for a variety of reasons, but in the case of passwords, the speed is what matters! Actually... the slowness! Algorithms such as MD5 or SHA-1 are designed to be fast, and this makes them a poor choice for hashing the stored passwords. Why? Because this makes brute-force attacks easier!

​

So... we want to make it harder to check every possible character combination to "guess" the password for the given hash, right? And here work factor comes into play! It is basically an input parameter for a hashing algorithm, dictating how computationally expensive it is to calculate the hash!

​

One of the widely adopted hashing algorithms allowing to specify work factor is... bcrypt! And this makes it a great choice for our need for hashing passwords! 🥳

​

ALERT ⚠ Rainbow tables may spoil our day ❌

​

But... hackers are very smart and they can use the so-called rainbow table to find what password was used to generate the given hash much faster... How is this possible? Because a rainbow table is a pre-computed list of pairs: PASSWORD-HASH. Boom! So, once they want to find the password, the speed of hashing does not matter, because all the hashes are already there! It's like a dictionary. Just find the hash and corresponding password 📕.

​

- Bartosz!!! So, how should I store users' passwords securely?!

​

Ok, ok... let me come to the third option, hashing with salt! To make rainbow tables useless, we just need a little bit of salt! Like making your dish taste better (haha!).

​

- Tell me! How does it work?

​

🚀 Straight to the point: generate salt (random value) for each password independently and append it to that password before hashing. Then append this salt to the hash. That's it! Rainbow tables are useless since they don't take into account the random salt!

​

When you want to verify the password (for example, during the login), just take the salt appended to the user's password hash and append it to the password you want to verify before hashing!

​

And... YES! bcrypt also incorporates salt out of the box! Check out its Node implementation here 🤓

​

Uff! We are done for today! 🔥

​

Rate this email:

​GREAT 😃 | OKEY 😐 | BAD 😟

​

Thank you for your time,
Bartosz