Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I have noted some sources indicate that when using a KDF like PBKDF2 (alternatively) some advocate injecting the salt at the time of execution - like this:

dv = salt + PBKDF2(salt + password, salt)

Versus the "plain" usage of

dv = PBKDF2(password, salt)

When using the PyCrypto.Protocol.KDF PBKDF2 function or Armin Ronacher's version (both linked above), do the extra salt parameters add any benefit if no two passwords will have the same salt (but the salt will be stored with the password)?

Presumably the risk is having an oracle whereby identical passwords would be revealed as-such, encoded. Is this the case or is there another concern one ought to be mindful of?

If this is the only concern I would expect, in the absence of a fault in the algorithms that permits short-circuiting, a plainly used salt obliges one to recheck every password the entire number of iterations. Is this the case?

(Incidentally, this is copied from my post on SO, which was inexplicably closed).

EDIT:

It is worth linking:

The last link in particular states, in the question:

As far as I know, the recommended/approved method for storing password verifiers is to store:

$verifier = $salt + hash( $salt + $password )

In a sense this question becomes "is it necessary to inject the salt into a KDF in the same way as is recommended for a hash"? (presuming of course that the theory supports the injection of a salt for a hash - though I believe it does)

share|improve this question
    
"some sources indicate" - Do you have links or citations to those sources? What argument did they give to support their position? –  D.W. May 7 '13 at 21:52
    
Thanks @D.W. - I had a quick look for them when I posted the question (on a tablet), but I can't find them now - I'll keep looking and post if I come across them. I suspect it may have originally come from a resource (for example) that suggests putting the salt before or after the password being hashed. –  Brian M. Hunt May 7 '13 at 22:31
    
Thanks, Brian. Yeah, that resource you linked to is talking about something different: it's recommendation for concatenating password + salt relates to use of a hash like MD5 or SHA1 (which don't have any built-in support for salts, so manual concatenation is necessary), but not to PBKDF2 (which does have built-in support for salts, so you don't need to do it yourself). Even the PBKDF2 code sample on that page doesn't concatenate the salt + password; it passes them separately to PBKDF2. –  D.W. May 7 '13 at 22:58
    
Regarding your edit: Understood. That last link does talk about concatenation, but it is talking in the context of an ordinary hash function (which does not intrinsically support a salt). That's different from PBKDF2. PBKDF2 is designed to support salts, so the answer for PBKDF2 is different than for a vanilla cryptographic hash. Oleksi's answer remains the correct one. –  D.W. May 8 '13 at 4:26
add comment

1 Answer

up vote 7 down vote accepted

Identical passwords will still get unique PBKDF2 hashes given a unique salt, regardless of which mechanism you use.

I don't think explicitly adding the salt improves the security of this scheme. The designer PBKDF2 have already considered and solved this problem. There is no need for you to try to duplicate their efforts.

I think it's safer to use the well tested and well understood construction of PBKDF2:

dv = PBKDF2(password, salt)
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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