2
$\begingroup$

I read a lot about the concept of adding a salt to a password and understand that it protects against rainbow table etc. attacks. But this kind of attacks are based on getting access to the server side stored password database. What if the passwords are never stored? Because the salt is per definition not secret, it doesn't help to make a weak password more strength (afaik only key stretching will help in this case, right?). Hence an application that encrypts only on the client side (user enters password -> KDF -> Key -> encryption) doesn't seem to have any benefit when feeding a salt into the KDF algorithm.

So, is it ok to set the mandatory salt parameter of KDF functions (e.g. PBKDF2) to a hardcoded value? Or do I completely overlook another salt feature? Thank you.

$\endgroup$
2
$\begingroup$

If you are dealing with encryption using user-provided passwords, the resulting ciphertext might be attacked using a "dictionary attack", that is somehow the same kind of attacks we are trying to mitigate using a salt to store the passwords, but not completely.

When encrypting with user provided passwords, the KDF is used as a mean to compensate for the poor entropy of the user passwords, but because you cannot consider the salt to be a secret and you have to provide it to the decrypting party in some way, if you use a salt, you risk to simply use a constant one, which changes not much or a password-dependent one, which also is not the goal of a salt, since the dictionary attack against encrypted data would still work by simply using the same parameters and salt as you do.

So in the end, you should be worried about making the dictionary attack as costly as possible and this is possible with modern KDF such as Argon2 or Balloon, where you can set the parameters, which can be publicly known, in such a way that the attack will be too time consuming and costly for the attacker.

So effectively, I agree with you that the salt is not necessarily useful for your use-case, however your use-case also mandates you to use a KDF designed for such cases, not just a hash function.

PS: notice that dictionary attacks are only useful when the adversary is able to tell easily whether she has found the correct key or not. Which is typically the case in known plaintext attacks, but not always true for all use-cases.

PPS: I'm not mentioning the pepper since you're aware of its existence given your other question. But a pepper is typically useful in that kind of use-case. Note that the salt, when considered secret is basically a pepper.

$\endgroup$
  • $\begingroup$ Thank you Lery for confirming my expectation and your further informations. I totally agree with you, that I have to use a KDF algorithm. A problem encountered in practice is that not all (available) crypto libraries support all algorithms (like Argon2). And adding a static pepper doesn't make sense in open source projects where the whole source code is public visible. That's why I asked in the other question if the random-pepper (now as dubious classified :) method could be an improvement. $\endgroup$ – User01638 Nov 11 '17 at 9:32
  • $\begingroup$ An additional question regarding the weak password problem and the missing Argon2/Ballon support: Does it help to chain two KDF methods? E.g. create a key with PBKDF2 (SHA 256) and feed the resulting key to HKDF (SHA 512)? I would assume that there is no advantage. $\endgroup$ – User01638 Nov 11 '17 at 10:00
  • $\begingroup$ @User01638 I cannot see any advantage besides maybe trying to anticipate a break of either... Which is really unlikely. Notice that PBKDF2 with sufficiently big parameters allow to avoid dictionary attacks as well thanks to the computational cost it would induce. $\endgroup$ – Lery Nov 11 '17 at 17:54

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.