7

I want to derive a key from a password in a client application that will be used as a master key that decrypts a data key. As far as I understand the salt should be private knowledge. Would it be enough to use the hash (e.g. SHA-1) from a password as the salt parameter for PBKDF2?

Again, as far as I understand, when the attacker would gain knowledge of this algorithm the salt should be worthless. But wouldn’t it be easier for an attacker to retrieve a generated, but stored, salt? I have to store it somewhere, because the key won’t be used only once.

Improve this question

3 Answers 3

Reset to default
15

A salt is not a secret, it is meant to make the Hash/PBKDF2 result unique to each used instance. As far as a know, the very definition of salt requires it to be random for each computed hash. If it was password derived, two users with the same password could end up with the same verifier -> Bad.

Improve this answer
2
  • 2
    A salt does not need to be random, it just should be unique. In principle you could use a combination of user number and site name, a V1 GUID,...
    – CodesInChaos
    May 15, 2012 at 21:54
  • 2
    Yes, technically, the salt should be unique and non-predicatbale. This is meant worldwide. Since there is no central organization which distributes unique salts on demand, we have to rely on the next best thing: random selection with an unpredictable random generator, preferably within a salt space large enough to make collisions improbable. It is tempting to try to derive a salt from some data which is "presumably unique", but such schemes often fail due to some overlooked details. Since it is comparatively easy to creating sufficiently random salt value, why bother with any clever schemes?
    – Jacco
    May 16, 2012 at 8:21
7

If the salt is derived from the password, then the complete password-to-stored-hash function is deterministic; two users using the same password will end up with the same hash. @Jacco has said that, but left the implication unsaid: if you use a password-derived salt, then you do not have a salt anymore, just a fancy unsalted hash function; and you lose the protection which the salt provides, namely to prevent attackers from using precomputed tables (rainbow tables) and using parallel attacks on a whole database of hashed passwords (or encrypted blobs with password-derived keys).

Improve this answer
2

You say you'll store the salt. That means in case an attacker gain access to the database, what do you prefer she gain access to ? the password/simple hash of the password, or a randomly useless generated salt?

It won't be easier for an attacker to gain access to the generated salt (if you store it where you would have stored the hashed password). It's the same level of difficulty.

But with the password/hash of the password, the attacker can access the master key AND find the original password (using rainbow table/brute force) that could be used in other account of this user.

If you store the salt, generate a random one.

Improve this answer
1
  • In the first case I wouldn’t store the salt, because it could be derived from the password the user entered. This smells like security through obscurity, though. So is it OK to store the salt for PBKDF2 alongside the encrypted key and IV, let’s say in a separate field of a table or as a header to the encrypted key? We’re talking about a single-user multi-client application that in most cases will store only one encrypted data key.
    – Rafael Bugajewski
    May 14, 2012 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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