In case of using client-side password stretching (plus a single hash on the server) - the server would need to send the salt before authentication, of course.

Though the salt is not considered a real "secret", is having the salt that public a serious consideration for rejecting this method (i.e. client-side password stretching)?

This answer (with more than 600 upvotes) says it's important to keep it secret. I know it's difficult to measure how important something is, but if you could give me some idea, that would be helpful. The reason to do it client side is to mitigate DDOS attacks.

  • $\begingroup$ Isn't the idea of a salt to make it harder to bruteforce hashed passwords if a database leak happens? If the salt is public knowledge it kinda loses it's purpose right? $\endgroup$ – AleksanderRas Jul 10 '18 at 14:57
  • 2
    $\begingroup$ @AleksanderRassasse No. Salts are stored in the database anyway. You might be thinking of a 'pepper' (that's not a joke). $\endgroup$ – ispiro Jul 10 '18 at 15:05
  • $\begingroup$ You're right, I mixed them up. My bad $\endgroup$ – AleksanderRas Jul 10 '18 at 15:11

Though the salt is not considered a real "secret", is having the salt that public a serious consideration for rejecting this method (i.e. client-side password stretching)?

Yes, it is better if the salt is kept secret, but the attacker still has to perform a full-on offline brute-force search even if they know the salt before a breach, it's just that this search can be carried out before a breach and then after a breach only a logarithmic effort per entry is needed for the lookups. And if they don't learn the salt, the "timer" at which brute-forcing starts is pushed back to the point where the database leaks.

Now this exact attack, the ability to pre-compute real-salt-based password hashes before an actual breach is part of the reason why OPAQUE, the current state-of-the-art asymmetric password-authenticated key exchange (aPAKE) exists, as no previous aPAKE defended against this kind of attack.

So TL;DR: Hiding the salt is better, but actually doing so may be considered too much work and it's not the end of the world if the salt leaks.

  • $\begingroup$ As for OPAQUE - I wouldn't try to implement it myself, and can't use any 3rd party library, and assume it's not part of .net yet. But for my knowledge, is it (or does it include) a client authentication system? Both of your links seem to imply (I only looked at them briefly) that both parties need to know the password. Not appropriate for client authentication scheme where we want the password to remain secure even if the server is compromised. $\endgroup$ – ispiro Jul 10 '18 at 17:46
  • $\begingroup$ @ispiro this is where the "asymmetric" part comes from: In aPAKEs the server only stores a "verifier" which allows the server to verify the client knowing the password without having to permanently store it (only learn it on setup perhaps). For OPAQUE this is essentially a public key and an encrypted corresponding private key. $\endgroup$ – SEJPM Jul 10 '18 at 18:08

There is a difference between the offline password guessing attack and the online password guessing attack. In an offline password guessing attack, the attacker can enumerate passwords and verify his guesses without the server knowing that. Thus it is devastating because passwords are often of low entropy, and the attacker can find those weak passwords with a reasonable low cost (despite key stretching is used).

The reason why the post in your question suggests not to make salts public is that if the attacker does not know the salt, he will be forced to perform an online password guessing attack, in which he has to interact with the server for each password he enumerates (to verify the correctness of his guess). At this point, the server can implement certain mechanisms, e.g. locking out the account after a certain number of logging failures or add delays to make guessing more time-consuming. This would counter the password guessing attack effectively and protect low-entropy passwords.

However, keeping the salts secret is not easy because they are stored in plaintext and meant to be non-secret (in fact if all passwords are of high entropy, the salts can be made public without any problem).

Because keeping salts secret is problematic, a more proper mechanism (in my opinion) if password security is a concern is to use a password-authenticated key exchange protocol that is secure against off-line password guessing attack (and this is achievable without requiring the salt to be secret).


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.