# Can a salt for a password hash be public?

For my understanding salts in password hashes are used to prevent the precomputation of $plaintext \to hashvalues$ (rainbow tables).

I know from different threads, it is not necessary to keep the salt secret (ie it doesn't need to be encrypted), but nevertheless I was wondering if it would be a problem by making it public?

The background of this question is the following idea:

For password authentication a strong hashing function like bcrypt or scrypt is used. Every user has it's own random and unique salt. However to minimize the load on the server, the hash is calculated at client side. For this to be possible a function must exist, that allows an unauthenticated user to retrieve the salt of any registered user.

-
It seems that this thread should cover your question? – figlesquidge Jan 4 '14 at 15:53
Salts aren't there to prevent pre-computation. They prevent multi target attacks. Rainbow tables are one particular example of multi target attacks, and a rather useless one. – CodesInChaos Jan 4 '14 at 17:05
Just like the similar question Is the salt value a secret or can it be stored in cleartext just like the IV?, this seems to be a possible duplicate of Can you help me understand what a cryptographic "salt" is? – e-sushi Jan 4 '14 at 19:16
It would seem that if "to minimize the load on the server, the (bcrypt or scrypt lookalike) hash is calculated at client side", the protocol is vulnerable to passive eavesdropping or disclosure of the hashes, followed by client simulation, unless encryption is used to transfer the hash from client to server; and even with that encryption, that the protocol is vulnerable to MITM, unless there is an initial secret key or public-key certificates. – fgrieu Jan 15 '14 at 17:47

The usual answer is that a salt can be make public; if that was a problem, then the salt would not be called a "salt" but a "key".

In some protocols, unauthenticated obtention of the salt is the norm, and is not considered to be a problem. E.g. with SRP, a password-authenticated key exchange, where any salting and hashing must necessarily occur client-side.

Some people have argued that if the attacker can know the salt in advance, then he can do precomputations. This is a gain for the attacker only in a specific scenario, where the context is such that the attacker must be able to crack a password within a very short time frame (say, one second) but has a few weeks to prepare for his one-second attempt, for a specific target user. This is a fringe scenario which very rarely applies.

-