Security Vulnerability – Password management

To build a web product and run it locally is easy. To deploy and make it public to the world is much more difficult. One of the difficulties we must face is the possibility of our website being hacked by millions of hackers surrounding the world. Therefore, knowing how to deploy is one thing, but knowing how to avoid being attack by all the bad guys is much more important. Day by day, hackers try to scan every hole in the security wall to attack the website. Therefore, as a developer, we are also a protector of our children, need to improve our knowledge of security. This series aims to identify some popular vulnerabilities a web product may encounter.

Part 1: SQL Injection

Part 2: XSS Attack

Part 3: Password Management

Part 4: CSRF and “Silhouette” Threat

---

Authentication exists in almost every web application. It helps the user to personalize their experience, as well as the application owner to analyze their results. So usually, authentication will require users to create a password. Now, the questions seem to be simple, yet still technically complicated enough, is how to store users’ passwords? How can we assure that even if a hacker can see our database, the users’ passwords still cannot be leaked? A quick note that this practice should be implemented not only in sensitive information websites like trading, finance. Even a simple website like reading news also should practice protecting user credentials. Why? Psychologically, people always tend to use one password for many websites. That’s why even when our website is not that important, leaking credentials will have a great impact on users since hackers can use it to access other important applications.

Let’s discuss from the weakest to the strongest way to store passwords in DB.

1/ Store as plain text

This is literally the easiest way to implement. What users entered, just put it in the database. If the hacker can have access, it takes like 0 seconds for them to put all these credentials on deep webs for sale. But not just hackers, any curious employee also can do this with just a simple glance in the DB. Needless to say, this is the worst to do, however, I think that still many websites out there still doing this.

2/ Use Encryption

Let’s add 1 level, using encryption.

So the idea of this is we will encrypt the password to a ciphertext. So let’s say if the user’s password is ” IAmJakeLam “, after encryption, the text stored in DB maybe become some random text “12ezsa31”. This looks ok though! However, encryption is reversible. This would mean that if the hacker can hack to the server, and see the source code, they can get the decrypt key to convert it back. So this is still dangerous.

3/ Use simple Hashing

So instead of using encryption, we can use hash. One advantage of hash is it not reversible (theoretically). So we can avoid the case mentioned above where users can get the key. However, with modern computers, this can still be dangerous! If the hacker’s computer is powerful enough, it can use brute force to try thousands or millions of time until it breaks the hash. In fact, not all hash function is safe. For example MD5 and SHA, SHA-1 is already broken years ago.

User passwords are also predictable. There are some common passwords that are used among millions of people in the world. And of course, this list is so easy to access, just by a simple search on Google. Wikipedia also has this list. This would make the hacking process even faster.

4/ Use Hash with Salt

This is like one more level of hashing. The idea is for each user, we will assign one salt value. This can just be a random text. Before doing the hash, we will append this salt to the password.

Let’s take an example where the password is “IAmJakeLam”. We will assign a random salt, maybe “xya” and append to it. So right now the text to hash is “IAMJakeLamxya”.

What’s the difference? This will make the hacker spend more time and effort. Because for each password to check, they have to append the salt and bear in mind that this salt is different across the users. So in the past, if they can run and scan the whole database, now with that amount of time, they can only do for one user.

However again, with modern computers, this method still not 100% safe. The reason actually depends on what we want to trade-off between user waiting time and user security. It depends on how we choose the salt and hash algorithm. The longer time to do the hash, the harder it can be broken.

5/ Use enhanced hashing, like bcrypt

This is an algorithm designed based on Blowfish cipher. There is an article on Auth0 explained quite detail about the logic behind here. So the main idea is that bcrypt allows us to manage the number of salt rounds. The higher this number, the longer it takes to hash the password, and also the longer it takes to break it.

If we use modern frameworks like Spring, Node, … this enhanced hash is very easy to implement, just importing some library and wools, it’s done.

6/ Use 3rd party authentication

Don’t reinvent the wheel! Giant tech companies like Google or Facebook has tons of experienced engineer in this area, and they put so much effort to create their authentication plugin. However, the downside is user data, of course, will flow to their sites. So if our website does not have really sensitive information, using 3rd party source is not a bad idea.

Other notes

Besides how to store the password in DB, it’s also important to practice some other password management. Some popular methods below can be used:

• Force complicated password: This is really common. We can force users to set the password having a pattern ( must have capital, number, special character,…). The great thing is due to the fact that this is so common, doing this is no longer a pain to UX, but still do in a proper way. Some website even takes a further step to analyze the password security level and then give feedback to user when they think the password is too easy to predict.

• Allow password reset: This is actually the result when we use hashing to store our DB. Because hashing is irreversible, if users forget their password, there is no way we can retrieve it back for them. Therefore, one popular way is to tell them to create a new one. The URL to reset password should also have an expire time, in case the hacker can access their email. If the user already logged in and wish to change their password, they should be asked to confirm their old password first.
• Tell the user to change his password after an interval of time: Some websites also try to add this feature to help increase the chance the password is leaked in the past.
• Prevent Brute-forcing: Many times the hacker can write a script to attack the server by keep sending a different password until it is correct. To prevent this, we can limit the number of consecutive times users can type the password incorrectly. When it reaches the limit, we can show a CAPTCHA and ask them to solve it. (I wrote an article about CAPTCHA here). On a more secure website, we can apply stricter measures, like blocking the account.

• Implement a timeout session, use HTTPS, encrypt the password before sending it to the backend.