I hope you find what you are looking for!

If you are a good developer you must assure that the user's privacy is maintained always and even database admin is not able to see the password of any user. If someone finds the credentials of the database then it will be easier for him to leak the details of all the users.

Let's consider we are storing the username, password of the users.

1. STORE THE PASSWORDS AS INPUT BY USER (DON'T BE NOOB)

You can store the password as the user enters or you can append the string of username or any other detail of the user that's unique with the password but this method is very vulnerable.

If you are running a small business, with just a few users whom you know very well, you may store passwords unencrypted. So, if somebody forgets their password, you can just look and tell them what it is.

The password should be a personal identification detail so that neither you nor any system administrator is able to look at the user’s password. In case, anyone is having database credentials they can get access of any user and can also guess the credentials of other accounts of him as well.

2. STORE THE ENCRYPTED PASSWORDS

Encryption makes it tough for guessing the password. You can even store the decryption key for the database stored on another server, get your password verification server to retrieve it only when needed. But with key system admin still able to decrypt the password.

The password data above has yet another problem, the DES encryption technique which produces the same data every time for the same passwords. Therefore, anurag and deven have the same password, even without the decryption key.

DES uses 56-bit keys and even though 56 bits gives close to 100,000 million million possible passwords but with modern CPU computation power, we can solve these many DES passwords within a day.

Therefore, we have to focus on three points. First, the password should not be recoverable from the database. Secondly, similar passwords should have different hashes. Thirdly, the database should not give any hints of password length.

3. HASH THE PASSWORDS

Hash is a one-way function with which you can get the hash of any message, but you can’t go backward from the final hash to the input password. Commonly used hashing algorithms are MD5, SHA-1, SHA-256. We’ll use the SHA-256 hashing algorithm. So even if system admin or anyone gets the database access still they won't be able to access the password.

As the hashes are of the same length, so there can't be any guess about the size of the password. Also, we do not need to limit the user's password length as the hash will convert it into 256 bits.

At the time of login, we compute the hash and match it with the stored hash. If both are same hash then we can let the user login.

But still, anurag and deven have the same hash so it is vulnerable as the password can be guessed. If you get the password of any one of them you will know the others password too.

4. COMBINE SALT AND HASH OF THE PASSWORDS

We can combine the hash that comes out for each password by mixing it with some additional data known as salt. Salt is also known as a nonce, which is a short form for “number used once.”

The easiest way is to put the salt in front of the password and hash the combined text string. The salt is not an encryption key, so it can be stored in the password database along with the username. It prevents two users with the same password to get the same hash.

Now anurag and deven gets completely different password hash. It is advised to choose good salts rather than using a simple random() function or increasing/decreasing numbers.

Now, here the problem is that the hash we have chosen is a single SHA-256 of salt and password. If somehow, the hacker has offline data of our database then he can compute hash with available modern CPU power by trying all possible password combinations that he can and try to login with that password.

5. HASH STRETCHING OF THE PASSWORDS

Mostly hackers try commonly chosen passwords and a combination of all letters and numbers. There is no limit other than CPU power to how fast it can guess passwords. This means that users who have chosen a simple password are more vulnerable to get their passwords cracked soon.

Therefore we can slow down an attack by running the password hashing algorithm as a loop that requires thousands of hash calculations. These are well known available algorithms PBKDF2, bcrypt or script algorithm.

HMAC-SHA-256 is a special way of using the SHA-256 algorithm that isn’t just a straight hash, but allows the hash to be combined comprehensively with a key or salt.

After applying these algorithms we need to add the iteration count, the salt and the final hash to our password database. You can increase the number of iterations for more safety. But it all depends upon the computation power of CPU and how many iterations will be good to make an attack slow.

When a user with a previous hash log in, you simply generate and update their hash using the new iteration count. So no need to update the password for safety just increase the iterations of algorithms.

Thanks For Reading ...

In future I will write a blog describing the code of how to use these ways and REST API for all these methods.

If anything is wrong here by mistake do let me know. I will read it further and make changes accordingly.

Please like it if it helped you in anyway or comment if you have any doubts regarding this or want to give some suggestions.