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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
ALEX
  • 13
  • 2
  • Your closed post https://stackoverflow.com/questions/63281065/secure-password-storing-algorithms already directed you to https://security.stackexchange.com/questions/36833/why-should-i-hash-passwords which has several answers; did you read those? Which specific parts are still unclear? – tripleee Aug 06 '20 at 10:59
  • Does this answer your question? [Does Hash/Salted password really help when DB is compromised?](https://security.stackexchange.com/questions/9018/does-hash-salted-password-really-help-when-db-is-compromised) – tripleee Aug 06 '20 at 11:00
  • not really. These posts explain how salt works, but I still do not understand, why is it better than hashing. – ALEX Aug 06 '20 at 11:06
  • You have the "what do we want to protect from?" part wrong. That's not why salting is considered the better way. – schroeder Aug 06 '20 at 11:25
  • hm... So why is salt recommended for storing passwords? – ALEX Aug 06 '20 at 11:27
  • And your last paragraph is not how an attacker gets passwords. – schroeder Aug 06 '20 at 11:27
  • I understood all articles I read like that: hacker checks some passwords (either brute force or common passwords) and gets the one that is used. If it is so, than only difference between hashing and salt hashing (as I uderstand) is amount of times hash function is ran. But I do not think it will slow down hacker's programm so much that it will be impossible to crack salt hashed passwords. Hashing algorithm will not be very fust, of course, but I do not think it has to work very long to make some noticable changes in time of cracking. – ALEX Aug 06 '20 at 11:33
  • " It will be a bit longer for hacker, but not a lot (I think)" -- an 8-bit salt multiplies the effort by 256. That's not common these days; my current system uses a 96-bit salt in `/etc/shadow` (16 characters from an alphabet of 64), 2^96 is 79228162514264337593543950336. That certainly *would* slow down any attacker, and forget about even building rainbow tables for all those combinations. –  Aug 10 '20 at 07:00

1 Answers1

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 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` – Mark Stewart Aug 06 '20 at 13:41
  • Good point about multiple instances of the same hash in the database. – schroeder Aug 06 '20 at 13:51