1

I have recently read an article about storing passwords safely and I have a few misunderstandings. I found out 4 ways of storing users' passwords:

  1. Just keep them in plain text
  2. Keep passwords in plain text, but encrypt the database
  3. Hash a password
  4. Use salted hashes of passwords.

The best way is supposed to be the 4th.

My main misunderstanding is about: "what do we want to protect from?" As I understand - from the case when hacker gets access to our server and gets the database and the server-side source code. In this case, I, as a developer, jeopardize accounts of those users who have the same passwords on all websites. Hacker gets a password from my database and then knows what password this user has on other websites/apps. That is why I want to to make passwords as secure as it is possible. In this case, I do not understand the difference between ways 3 and 4 (1 and 2 are obviously bad, I think).

To crack passwords in way 3 the hacker gets my hashing algorithm and just tries to hash some passwords (either brute force or maybe some db of common passwords) and compare gotten string to the database. To crack way 4 the hacker has to try passwords like in the way 3, but, when hashing, his program will just take stored random string from my base and use it when hashing. It will be a bit longer for hacker, but not a lot (I think). So why the way 4 should be a lot more secure than the 3 one, or what do not I understand in the 4th way?

8

1 Answer 1

2

Does Hash/Salted password really help when DB is compromised? really does answer your question, but there looks like there is a language issue. So I will explain in a different way.

If we only hashed passwords, and not salted them, then commonly used passwords would all look the same. The password password in MD5 on every system in the world will always be:

286755FAD04869CA523320ACCE0DC6A4

Tables and databases of hashes of these common passwords exist. For fun, look up that hash on Google. So if an attacker gets the password database, they can look these up and know your user's passwords to log into your system. It takes very little time, and very little work, to discover the password. And they can do this very quickly for each password in your database.

If more than one user uses the same password, like if they used password, then all those passwords will have the same hash, which makes it even easier for the attacker to look them up, or try to brute force the one hash to discover multiple user's passwords.

Adding a salt makes these hashes unique in your system, even if the password is still password. For instance, if you add iamasalt to password you get iamasaltpassword and that hashed in MD5 is:

B27EB5B892E89369497C2DD9749667AF

Even though the password is still password, it is stored in your password database in a unique way so that the tables and databases of common password hashes do not work. An attacker might know the salt, but now the attacker has to go through the work of figuring out what the password really is for each and every password. Knowing the hash is not so useful anymore.

By having a unique salt for each user, then even if users use the same password, that fact will not be known by the attacker unless all hashes are brute-forced. They cannot break one hash and get access to multiple accounts.

Salts stop the attacker from simply looking up the hash in a table or to crack one hash and get access to more than one account. And it forces the attacker to brute force the hash of each password.

2
  • A couple decades ago, I had access to a corporate user ID database, and I queried the hashed passwords column, noticed that a hashed password that occurred about 12 times was used by someone in my team. And he was a Trekkie, and I bet his password was NCC-1701 Aug 6, 2020 at 13:41
  • Good point about multiple instances of the same hash in the database.
    – schroeder
    Aug 6, 2020 at 13:51

Not the answer you're looking for? Browse other questions tagged .