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?

2 Answers 2


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.

  • The only part of this that is semi-relevant to the question, "it may be good, but it is hard to know for sure" won't be accepted as an answer. The rest is idealism and criticism for even asking the question. e.g. off topic. Commented Aug 16, 2013 at 2:35
  • @StrandedPirate actually the whole answer is perfectly relevant and correct, even if it presents some of the scientific theory and background instead of just giving you the simple answer. To sum up: (1) In a perfect hash world, it would not matter; (2) we do not have a perfect hash, so we are not sure; (3) you are not a cryptographer, so don't try to create this yourself ("Don't be a Dave"); (4) Besides the salt, you're doing it wrong (use a slow scheme designed for protecting passwords).
    – AviD
    Commented Aug 16, 2013 at 14:54
  • I don't know is NOT an answer, neither is "in a perfect world blah blah ..". in the process of getting it moved to the cryptography site were the real experts would be able to actually provide an answer. Commented Aug 16, 2013 at 15:13
  • 2
    Technically, I am a "real expert" in cryptography, and I don't say "I don't know". Instead, I say: "cryptographers have come to the conclusion, after decades of research, that it intrinsically cannot be known". The only known method to "guarantee" that an algorithm is safe is to make it public and let other cryptographers try to break it for several years.
    – Tom Leek
    Commented Aug 16, 2013 at 15:57

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.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .