5
$\begingroup$

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)

Improve this question
$\endgroup$
4
  • $\begingroup$ "some sources indicate" - Do you have links or citations to those sources? What argument did they give to support their position? $\endgroup$
    – D.W.
    Commented May 7, 2013 at 21:52
  • $\begingroup$ 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. $\endgroup$
    – Brian M. Hunt
    Commented May 7, 2013 at 22:31
  • $\begingroup$ 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. $\endgroup$
    – D.W.
    Commented May 7, 2013 at 22:58
  • $\begingroup$ 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. $\endgroup$
    – D.W.
    Commented May 8, 2013 at 4:26

1 Answer 1

Reset to default
8
$\begingroup$

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)
Improve this answer
$\endgroup$

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.