1
$\begingroup$

So I was reading through an article about how passwords are salted and hashed through a cryptographic function here, and found out that hashed passwords, along with the plaintext salt values are stored in the database.

Now, I was wondering: if both the hashed passwords and salt values are stored in the database, if hackers somehow have access to a password and can access the database and therefore, access all of the salt values used to generate the hashes for all the other passwords, wouldn't it make the salt completely pointless anyway as hackers would already know that they simply have to add the appropriate salt values at the end of the password and guess the password as normal, while assuming that 2 or more users in the database are using the same password?

For example: we have a password called “password123” which hackers have stolen and gained access to, and we also have a database of hashed passwords and salts here.

Salt: “Shelly”

Hash: 1753cd301ed0a04fc50cfb0470b0694aed5191cd0e7e49352ccfcd12ff9f268e

Salt: “Colt”

Hash: ce6cea9e3bf26b324367e117878630e0d172a9fca645b5ca744e18748f7c93ab

If hackers assume that both the hashes might lead to the password “password123”, then the first thing that hackers might do is append both the “Colt” and “Shelly” salt values to the password, and then hash it, before trying other password combinations by brute forcing, which could do nothing to actually improve the security of all the other passwords if both hashes shown actually correspond to the same password

$\endgroup$
1
  • 4
    $\begingroup$ Salt and hashed password are NOT purposely made public. They are assumed public when we analyze security after a hashed password+salt database leaks. A modern hashed password is not the SHA-256 of the concatenation of password and salt (as in the question), which would be extremely insecure after such leak; instead, it's used a purposely slow hash, preferably a memory hard key derivation function like Argon2 or scrypt. Salt is here to make it impossible to amortize the cost of hashing candidate passwords across several users, and defeat rainbow tables and other attacks before such leak. $\endgroup$
    – fgrieu
    Commented Apr 8 at 16:14

1 Answer 1

4
$\begingroup$

The difference is how the brute force attack scales: Without salt, the hacker can just hash the most likely passwords and then scan the whole database for the corresponding hashes. One succesful brute force attack then will automatically reveal all other users who use the same password.

With salted passwords, if the hacker successfully can get one of the passwords, he cannot detect the other users with the same password without re-calculating the hash with their salts.

So the hacker must run a new brute force attack for every salt.

$\endgroup$
2
  • $\begingroup$ Yes, but if the hacker works under the assumption that most if not all of the passwords are the same (which maybe could actually be true), then having a salt would be ineffective. I don’t know, I’m probably overthinking this. $\endgroup$
    – mantot123
    Commented Apr 8 at 16:58
  • $\begingroup$ @mantot123 The purpose of the salt isn't to make guessing impossible; it's to slow guessing and make outputs unique. A pepper is what you want if you want to make guessing computationally infeasible because it's a secret value that's high in entropy. When possible you should use a salt and pepper. For example, you can encrypt the password hash using an AEAD with the pepper as the key. Some password hashing algorithms, like Argon2, also have a key parameter for the pepper. $\endgroup$ Commented Apr 8 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.