Salt placement prior to one-way hash

Question

In one-way hashing its common to prepend or append the salt to the secret and then hash it: (salt + secret) or (secret + salt). I was thinking of this metaphor as salt falling on a plate of food. It of course doesn't all fall either at the beginning or all at the end of the plate.

Is there any security benefit if instead I were to randomly distribute the salt within the secret like below?

Simple example where salt is distributed every other letter:

Salt = lk2jn35  
Secret = hello  
Salted = lhke2ljlno35

I’m sure I could also come up with a “mask” variable that describes the distribution of the salt in the secret and the distribution of the salt itself could become random like this:

Salt = lk2jn35  
Secret = hello  
SaltMask = 010011101011  
Salted = hlelk2jlno35 

The question though does this have any additional security benefit above and beyond the traditional prepend or append method?

Answer 1

How the salt and the password are mixed together has no importance whatsoever IF the hash function is "perfect" (i.e. is a random oracle). However, perfect hash functions don't really exist; we don't even known if even "slightly imperfect" hash functions can exist at all (functions which are not random oracles but still guaranteed to be preimage-resistant). Practical hash functions have "quirks" which relate to their internal structure, and must be avoided by taking care of how the input is prepared. It is extremely hard to tell which way to combine password and salt is better, so the normal way is to leave it to trained cryptographers. These people have come up, after decades of work, with some constructions which seem to be strong, and it is improbable that a lone developer could come up with something significantly better by slapping together one or two functions.

In any case, even if your method of mixing the password and the salt is good (it may be good, but it is hard to know for sure), your function is still way too fast. You should have thousands or even millions of nested hash function invocations here, because a password hashing function ought to be inherently slow. See this answer for a complete treatment of the question.

Answer 2

See Why is it always `HASH( salt + password )` that we recommend? . If you are looking for a secure method of password verification there are better options, as Thomas Pornin points out in his answer to that question, and Tom Leek points out above.

The H(salt|secret) method may be susceptible to length extension attacks though I can't see a way that it can be useful in this context (since one must know both components to carry out this type of attack, there's no benefit), there's no reason to dismiss it immediately.

Assuming the chosen hash algorithm is fit for purpose, then I suggest the following considerations:

• The purpose of salt is not to "improve" the hash, it's to make it expensive to perform certain precomputed attacks
• Salt concatenation is a computationally trivial operation, and no where near as effective as proper key-stretching in terms of expense. Shuffling bits around a handful of times is a comparably trivial operation.
• Given the intent of a salt as used here, one thing you can say is that a longer and more random salt is better at its intended purpose. It follows that it doesn't make the salt more (or less) effective if you simply shuffle bits of input around.

Assuming "better security" is equivalent to "harder for an attacker", there is no benefit because the attacker knows the system and the challenge is no more complex than before. The secret is still the same secret, and the amount of work to do to recover it is practically unchanged.

(And, as ever, there's the risk that you've either overlooked some subtle aspect of the system, or are just plain unlucky today, and you've somehow managed to make the overall security worse.)