PBKDF2: can the salt be known from the hash?

Question

I understand that some KDFs bundle the salt with the output, such as bcrypt (modular crypt format).

In PKCS5_PBKDF2_HMAC (specifically, looking at OpenSSL implementation) with a single iteration, is the salt knowable/attackable?

I am staring at a KDF implementation that runs a single iteration of PBKDF2-HMAC over some data, using the user password as the salt.

Is the salt at risk of being discovered/is this a proper use of PBKDF2?

(The data being hashed is itself output from the same KDF, but with a proper iteration count.)

---

  // hash 1 is not transmitted over network, and it used for symmetric encryption
  hash_1 = pbkdf2(salt=username, data=password, iterations=5000)

  // hash 2 is transmitted over network, as a password for auth 
  // is the salt vulnerable?
  hash_2 = pbkdf2(salt=password, data=hash_1, iterations=1)

Answer 1

EDITED:

My first instinctive response was DON'T EVER USE THE PASSWORD AS THE SALT VALUE. And that's still pretty much where I'm standing.

However; reading your post a little more carefully, no the salt is not stored in the result from the pbkdf2 algorithm.

However; the purpose of the salt is that it adds entropy (randomness) to the input data before hashing.

Salt is really not intended to be "secret."

The first glaring problem I see is the use of the username as the salt value in the first call to pbkdf2. That's totally predictable. Why is that not using a randomly generated salt value that is stored along with the username and the password hash? (The password itself should never be stored anywhere).

Anyway, it's safe to say the salt isn't stored or transmitted by the KDF because it is an input that is used to generate a one-way, mathematically non-reversible output value. The salt itself does not exist in the output.

But both usernames and passwords are rather poor choices for "salt" values because neither is sufficiently random (sufficiently safe from duplication). Passwords in particular are highly susceptible to duplication over a large set of accounts. Lots of people end up using same passwords.

But if you add randomly generated salt to identical passwords before hashing them, then the resulting hashes will be completely different from each other.

On the other hand, having identical (predictable!) salt values on multiple accounts or multiple data streams is bad news because it introduces a degree of predictability and potentially opens the door to exploits.

EDIT #2:

Hashes and salt... since there seem to be some additional qustions and comments on this subject, the bottom line is that cryptographic hashing algorithms are deterministic (the same input into a cryptographic hashing algorithm always produces the same output).

If this was not true, then these algorithms would not be useful.

The issue from a security standpoint is that if you do not "salt" your input data (typically, passwords), then the hashes you store or transmit are no more unique than the original data.

So if you crack one hash (dictionary attacks or rainbow tables), then you've cracked every one that matches. This is exactly what led to (can I identify a major business social media site by name?) having something like 6 million accounts compromised a couple of years ago.

"Salt" was just a cutesy acronym back in the green-screen days for entropy (randomness). It's cute to think of "salting" your "hash" (putting salt on hashbrown potatoes or corned beef hash or whatever).

The purpose of the "salt" is to randomize the input (the password). If the salt is randomly generated, it will be completely unique for every password. Append it to the password, and all of a sudden every password is unique even if thousands of users all choose the same password.

The salt value itself is generally not meant to be a secret. It is often stored right alongside the hash value (or even appended to it), and the original data secret itself (the password) is never stored.

So when the user provides the secret, the salt is appended to the provided string the same way it was when the hash was originally created, fed into the hash algorithm, and if the result matches the stored hash you know the user provided the correct password.

What @Fleche is saying about usernames not being globally unique is true, and passwords aren't even very unique in small domains, let alone globally.

Using both the username and the password as salt this way might open you up to an attack that you haven't really anticipated. The username is predictable and not universally unique even though they're unique in your domain. But then salt values are generally not secrets anyway. So you might be safe. But it feels a little sketchy.

Answer 2

A “salt” which is derived from the input data is no salt at all. In other words, this is an unsalted hash function which only takes a password and an iteration count and calculates the resulting hash. If the iteration count is constant, then the same password always yields the same hash.

The whole point of the salt is that it's additional input. Contrary to popular belief, it's not secret in any way, but it must be sufficiently random.