Dev. Bites: No to plain text passwords in Database, but…

To the newbies developers, who are told to build an application which includes storing secrets (Login, OTP, etc)

It is a common practice that you are not supposed to plain text passwords in database. So probably you encrypt (The common term is used where one can retrieve passwords back). Nope.

Passwords should not be stored in a way that can be decrypted too. Since Anyone with the encryption / decryption key can still decrypt.

Welcome to Hashing!!!

One would use a hashing algorithm like MD5, SHA. Hashing is one way. You cannot retrieve it back. Common industry practice talks about using SHA512.

So now hash your password and store in database. Take password from users next time and generate hash and compare hash from database and there you are, A SUCCESS LOGIN.

Solved!!! Wait Not yet…

Suppose Bob has password Hello@1234, hash generated will be 07dbb6e6832da0841dd79701200e4b179f1a94a7b3dd26f612817f3c03117434

Now Alice has password Hello@1234, then she will also have the same generated hash.

Anyone with the access can easily make out that password is same.

Also, lets assume that Bob and Alice have different password and so is their hash generated is different too.

If Godwen (:p an internal user), has access to database with breaching intentions. He can replace the hash mapped to Alice with his hash (update query), login to her account and then replace back. DANGEROUS!!! Isn’t it?

What does internet suggest?

Create a salt (random text) for every user, hash the password with salt (Hash this “HGHJGJHello@1234”, notice HGHJGJ is the salt) store this hashed output in your database along with plain text salt in separate column. Next time prepend salt (from database) to the password from user, hash, then compare with database hash. SOLVED!!! Not Yet!

He can even replace the random salt too. 😉

If you don’t have strong production practices no ones going to know.

Solution

Why not prepend unique user id as salt to password before hashing. This way he cannot afford to change the user id mapped in every other table and thus makes it more complicated for anyone to break.

Obviously you can add more practices like no. of attempts. to limit and disable the account. etc.

So next time when you store password as hashed. Better use the user id as salt.

Thanks for reading.