Today’s topic is quite interesting. Here’s the question I’ve been asking since I’ve been using the internet:
Will Facebook know the password when I create an account there?
I’m sure many of you have the same question. And in this article, let’s learn how passwords are stored, and then find the answer to the above question.
1. Plain text or encrypted?
Okay first part, let’s start with two of the most common ways to store passwords in the database. I will go from insecure to higher security levels.
1.1. Plain text
The first is how to save passwords to the DB as plain text. Basically we don’t do anything with the password, just save it directly to the DB.
This is a very insecure method, if a hacker attacks the system and gets the DB, all of the user’s passwords can be easily viewed.
Users often have the habit of sharing passwords for many places. Passing Facebook, Google, banking, … is often the same because of being afraid to remember many passwords. Therefore, if you know a password, you can occupy many other types of accounts. Dangerous yet.
This is a slightly better method than plain text. Specifically, the password will be encrypted (encrypted) before it is put into the DB. When the user is logged in, there are two ways to check:
- Encrypt the password sent by the user, compared with encrypt in DB or not
- Decrypt the password in the DB, compared to the password the user posted
Either way, encryption alone isn’t secure enough. Just knowing the encrypt algorithm, hackers can write scripts to batch decrypt. The results are still revealed as usual.
2. Hashing, think the opposite
2.1. Password hashing
Hash is a special form of encrypt. Encrypting a string A to string B, then it is always possible to reverse decode from B to A. Hence, the encryption algorithm is called a reversible algorithm.
However, hash is a one-way encryption, so when hash string A becomes B, it is impossible from B to find A.
Therefore, the next level of password security is to store only the hash in the database. It works as follows:
- When the user registers, the system receives the password
- Hash the password and store the hash code in the DB
- When the user logs in, get the password sent by the user, hash it and compare it with the hash in the DB
- If the two hashes are the same, then the password is the same
Hash will have a collision, for example two different strings A and B have the same hash. Therefore, hash algorithms are chosen so that they are as few collisions as possible.
At this point, you can think that hashing is safe enough. But no, I thought the same way before, but soon I realized that wasn’t true.
John: My password has been hashed, you cannot know what my password is
Hacker: Oh really
Hacker: Your password is 12345, right?
John: How do you know? It has already been hashed.
Hacker: Yes, they have been hashed, but our hash is the same, and my pass is 12345
Hacker: Not only the two of us, but 12345 other users also share the same hash
See, through the example above you also understand why the hash is not secure enough. Maybe if our password is set harder, it will not easily be duplicated, but why would hackers like to get your password?
2.2. Why would a hacker want your password?
Hacker: Why should I get your account, when I can get another 10000 accounts much easier.
That is the opposite way of thinking. You think your private password cannot be detected, your account is secure. But overall, hackers are not free to hack your account, but most other users. You just accidentally got into that number.
A system is rated as safe or not, regardless of whether your account is vulnerable to hacking or not, but on the whole. Therefore:
- You set a strong password, your account is secure
- The system must be powerful enough to protect not only you but also many other users
This article mainly presents the second idea, ie overall.
2.3. Brute force and dictionary attack
Here are two techniques used to attack a system using hashing to store passwords:
- Brute force is to generate a bunch of possible passwords and try them one by one. This is slow and will only detect simple passwords. However, if you have a strong computer and a fast hashing algorithm, you can detect a lot of passwords.
- Dictionary attack is to use a list of common passwords, like 12345, anhyeuem ( this password is already on top of the world), qwerty,… The advantage of this method is that it can detect quite a common account.
However, how to avoid it is quite easy. We just need to add the function to wait 10 seconds, 30 seconds, 5 minutes, … after entering the wrong pass more than N times, it’s okay. Or use reCaptcha. However, in case the hacker attacks the database and has all the data, the above method is also useless.
3. So how?
To be more secure, there are four next ways to increase the security of hashes.
3.1. Use a slower hash algorithm
Although the above hash password is not secure enough, we do not remove it altogether but share the hash with other techniques for more security.
Hash has many hashing algorithms, also need to be selected accordingly. For example both SHA-512 and bcrypt are hashes, but bcrypt is many times slower (10000 times) should be chosen (making it harder for hackers to hash because it is slow). In addition to bcrypt, there is also scrypt, and PBKDF2 are all slow hashing algorithms commonly used in password security.
In addition to slower, more memory-intensive, branching, and repeating algorithms are also included. This is understandable because hackers will use the GPU to calculate (faster), when encountering CPU-oriented algorithms (iteration, branching, …), the GPU will become less efficient.
3.2. Add salt
Yes, you are not mistaken. Need more salt (salt) to the password before hashing so secure. Basically, salt is a random string, appended to the password string and hashes both. Hence, duplicate hash codes (as in the story above) are avoided.
password <span class="token operator">=</span> <span class="token function">hash</span> <span class="token punctuation">(</span> salt <span class="token operator">+</span> password <span class="token punctuation">)</span>
Previously, people stored hash and salt separately, but then it was easy for the hacker so they put the salt together with the hash.
3.3. Add pepper (pepper)
Spice it up a bit more for the password before the hash. Pepper is also a chain like salt, but secret and shared by all users (salt is different from time to time). In addition, salt is stored in the password, while pepper is usually stored in the source code (kept secret from the database).
password <span class="token operator">=</span> <span class="token function">hash</span> <span class="token punctuation">(</span> pepper <span class="token operator">+</span> salt <span class="token operator">+</span> password <span class="token punctuation">)</span>
3.4. Increase the number of hashes
The hash formula shown above isn’t just done once, it’s too simple. People will hash like that about 10 times in a row, the number 10 called salt rounds , or number of iterations. And the amount of time it takes to decode increases exponentially, for example a salt rounds of 10 will take 2 ^ 10 times more time.
Therefore, the safest way to store passwords is a combination of the four methods above. And due to the complexity of the algorithm, most security frameworks support the generate hash functions, making it easier to implement.
And finally, back to the original question, we’re sure everyone has the answer.
If a system is as secure and secure as Facebook, then not even Mark Zuckerberg can see the user’s passwords
Storing passwords securely in the DB is only a very small part of security. Hackers have countless different ways to attack, but if the password is saved properly, the hacker will not be able to know your password.
The article has a reference (for reference only) at the source https://www.vaadata.com/blog/how-to-securely-store-passwords-in-database . Thanks for reading the article, and if it feels good, please upvote the article to support me.