Does the position of the salt improve its effectiveness when hashing?

Question

Seems most documentation I have read suggests the salt should prefix the value to be hashed. Is this just for consistency, or is the salt more effective when prefixed?

Answer 1

If the hash function is a random oracle, then the salt can go wherever you wish, it will do its job.

On the other hand, there is, arguably, no such thing as a random oracle. On an existing, real, tangible hash function, details on how you input things may or may not trigger slight structural weaknesses in the function, which could impair the role of the salt, which is to prevent an attacker from doing exhaustive searches ("dictionary attacks") in a parallel way (time-wise or space-wise). In particular, on Merkle-Damgård hash functions (such as MD5, SHA-1 or SHA-256), the so-called "length extension attack" may be relevant.

So this is a matter of some delicacy. It seems best, generally speaking, to use constructions which have benefitted from wide scrutiny by many people. Salts are from the password-hashing business, and known good constructions for transforming passwords into keys are PBKDF2 and bcrypt.

Answer 2

I'd be very surprised if it actually mattered for password hashing whether the salt was added before the password, after the password, in the middle of the password, XORed with the password or mixed with the password in any other reversible way.

The actual security property required of the hash function in password hashing is a modified form of (first) preimage resistance: given the salt and the output of the hash, there should be no substantially faster way than brute force for an attacker to find a password that, after salting, hashes to the given output. This is a very weak security property, and if a hash function turned out to lack it in any form, that hash function would almost certainly be considered broken for other purposes too.

(One theoretical advantage of prepending the salt is that, for typical Merkle–Damgård or similar hashes, if the length of the salt equals (or is a multiple of) the block size of the hash, then the security of the salted hash can be reduced to first preimage resistance of the underlying hash function with a random IV. However, this reduction does not directly apply to the usual case where the length of the salt is not necessarily a multiple of the block size. Also, I believe a similar reduction could be used to argue in favor of XORing the salt with the password instead, even for arbitrary hash functions and salt lengths.)

On the other hand, for other superficially similar constructions, such as hash-based message authentication codes, the difference does matter (although in that case it turns out that neither prepending nor appending the key is really secure, and a more complicated method such as HMAC should be employed). For some examples, see section 6 of the original HMAC paper by Bellare, Canetti and Krawczyk and the references (particularly by Preneel and van Oorschot) cited therein. The reason for this is that the security properties required of a MAC are substantially stronger than those needed just for password hashing, and there are various attack scenarios that apply to the former but not the latter.

In any case, I'll second Thomas Pornin's advice that, in the absence of a good reason to do otherwise, it's generally safest to follow established practice. PBKDF2, for example, has been around for over a decade and is widely used. If there were any significant weaknesses in the way the salt is used in it, presumably someone would've spotted them by now. Which, really, is about the best one can often say in crypto. (In fact, with PBKDF2 we can say more: for example, if PBKDF2 is instantiated with a keyed MAC as the PRF, then a password recovery attack on PBKDF2 translates directly to a known-message key recovery attack on the underlying MAC.)