LAME Question of the Day: How To Store a Password in a Database?

30% of websites store plain-text Passwords:

If your password is stored as plain-text by the website, it clearly means that you are not secure and your identity is at risk. Someone can steal your password and if you are "one of those guys" that uses the same password for nearly everything, then I can only say, "Pray for Yourself". According to plain-text Offenders, over 30% of the sites store plain-text passwords and put your identity at risk.

The Less-Bad Approach

This approach is slightly better than the previous one. Instead of storing the user passwords as plain-text, we can hash the password using a one-way hash function like MD5 or SHA-1 and store the hashed value into the database. To complete the given assignment using this approach, I can hash the user passwords before storing it into the database as follows:



I have intentionally kept the password TextBox visible because I wanted to show you that I've entered the password as "sahil123" and using a hash function it is stored inside the database as a hashed string "4aa4029...0e8". Let's take some time to understand how this approach actually works.

How the hash function works

To explain this approach at the very basic level, consider a box of Mangoes and you want to make a Mango shake from it. You put the Mangoes into the mixer, start the mixer and your shake is ready. The key point to note is that you cannot make Mangoes from that Mango shake, that means the process is only one-way, the same principle applies to one-way hash functions.

A hash function is a one-way function that takes a string as input and transforms that input to a fixed-length hash value that represents the original string. The input string is called the message and the output hash value is called a message digest or simply digest. This approach is commonly used because the output hash value is considered nearly impossible to inverse, however some hackers are successful in reversing the process.



So, instead of storing plain-text passwords, we store the output of a hash function into the database. You might be wondering how to authenticate the user if we cannot return to the plain-text password from a hash. In fact, we don't need to. To verify if a user has entered a correct password during log-in, we use the same hash function on the input text by the user, then compare the newly constructed hash with the hash we've stored in the database. If they match, then the user is allowed into the site, otherwise an incorrect password is displayed.

Major drawback of this approach

You might be thinking that this approach is better than storing plain-text passwords and while your passwords are stored as hashes that are difficult to crack, you are secure. Let's do it. Hold your Horses for a second, there are certain drawbacks with this approach as well and you should be aware of them:

1. Suppose two users have entered the same password during registration, so their hashes are also the same and stored into the database as the same. This is called Hash Collision and if a hacker is able to find the password of one of these users, he technically can have the passwords of all the other people with the same password.
   
   
2. Another problem with this approach is the commonly used hash functions. Most of them, including MD5 and SHA-1, are not completely "one way" and are considered broken. Several security experts advise avoiding such functions for hashing.
   
   
3. Since this approach is better than storing plain-text passwords, it is possible for hackers to try and guess your passwords with techniques like Dictionary Attacks using the existing standard Rainbow Tables.
   
   
4. The biggest blunder resulting from this approach was: LinkedIn Hack.

The Good/Recommended Approach

I was reading about database security the other day and stumbled on a very nice article [^]. It was only then I realized that I was doing the wrong approach all this time and should change. Until now in the article, we are able to obfuscate the password from someone viewing it directly from the database, but it is still possible for hackers to try-and-guess the password. We need to take extra measures to secure the password and this is where this technique is useful.

In this technique, instead of hashing the password alone, we concatenate the password with a unique random string called the salt then hash the obtained string using a hash function and then store the salt and hashed value into the database. Using this approach, we have added one more layer of security for passwords and even if two people have entered the same password, their salt will always be different and the hash produced should never be the same.

To complete the given task with this approach, I need to modify my database a little bit and add a column to store the salt. It may be noted that the salt should be unique for every user, otherwise collision can occur. The modified layout should be like this:



If you're interested in the actual implementation of this approach using ASP.NET/C#, this article will be beneficial for you [^].

How this approach works

To explain this approach in simple terms, let's take the same example of Mangoes. We know that we cannot convert a Mango shake into a Mango but by tasting the shake we can detect that the shake is made from Mangoes and this is the problem with the previous (salt-less) approach. To make it more secure, we can mix some strawberries and apples with Mangoes in the mixer. In this way, the resulting shake is not a "Mango shake" any more and turned into a "mixed shake", so to guess the original ingredient is quite difficult.



With this approach, we can make the database more secure for hackers to attack. Some of the important things to note when using this approach are:

1. The salt should always be unique and randomly generated for each new password, otherwise it won't be useful.
   
   
2. The one-way hash function should be secure and slow. Avoid using MD5 and SHA-1, instead use bcrypt.

Conclusion

We have seen three approaches for storing user credentials into the database. The “plain-text” approach should never be used. The “salting and hashing” technique seems secure and makes it difficult to crack for the hacker but it is never impossible to hack a database. We can only make the process harder. I'm not an expert in security, only a beginner. This article is the result of my studies and understanding of database security. I may have missed several important points or conclude multiple meanings in this article. I would love to learn more from anyone out there. Your feedback and constructive criticism is always appreciated, keep it coming. Until then try to put a ding in the universe.