In this answer, Gilles says (emphasis mine):

There's no need to hide the salt from the attacker: it needs to be unique (and not derived from the password) but it doesn't need to be more secret than the hash.

I'm wondering whether there's any additional advantage to be gained by modifying the salting based on some characteristic derived from the password.

As an example:

Database:  Username | Hash | Salt

var passwd = "foo";
var len = passwd.Length();
var hash = hash(passwd + len + salt);

Does this have any advantage over the standard logic of

var passwd = "foo";
var hash = hash(passwd + salt);

aside from making the "password" portion longer?

One scenario where I feel like it might make a difference is a brute-force lookup based on common passwords. If password1 is actually hashed as if it were password1|9, for instance, then attempting to hash password1 with the known salt wouldn't provide a match. But I don't know if this is a common way of attacking password hashes, or whether it would actually matter.

  • 1
    What sort of attack vector(s) are you considering with this?
    – Kitsune
    Commented May 8, 2013 at 16:09
  • @Kitsune - I hadn't thought about it. It's just idle musing inspired by the other answer.
    – Bobson
    Commented May 8, 2013 at 16:17

4 Answers 4


The point of a salt is that it is unique, so that an attacker who wants to crack multiple hashes has to do all the work afresh for each hash. If you include a characteristic that is derived from the password, it doesn't help the salt. It doesn't hurt, either, but it doesn't strengthen the salt in any way.

In effect, by taking hash(password+length+salt) instead of hash(password+salt), you're using a different hash function hash2(password+salt) where hash2(x) = hash(x+length(x)). You are effectively inventing your own cryptographic primitive. That in itself is a bad sign. I don't think the result is actually insecure in any way, but I'd still veto it as an unnecessary risk.

hash2 is very marginally slower than hash. Slower is good for a password hash, but there are better ways of making the hash slow — password hashing functions have a tunable parameter to configure the slowness of the hash. Using a variant hash isn't worth the added complexity.

The normal method to generate the salt is to make it random. If you're going to add anything to it, the only point would be to mitigate a bug in the random number generator. If you're going to do that, take something that does not depend on the password, such as the user ID or the time.

Be careful with taking the hash of a concatenation of two strings: it's ambiguous: hash("bob" + "swordfish") = hash("bobsword" + "fish"). Whenever you take the concatenation of some strings and hash them or otherwise use them in a cryptographic protocol, make sure that the strings can be decomposed unambiguously. If there's a byte value that can't occur in either string (null bytes are often suitable), use that as a separator. If there is a bound on the length of the first string (264 is often suitable), prepend the length (itself in a fixed-size encoding, e.g. 8 bytes for a 264 length limit). If you're building complex data structures, use your library's ASN.1 module.

In any case, when you need to store a password hash, you shouldn't think about cryptography. Use your programming environment's bcrypt or PBKDF2 or scrypt library.

For everything you wanted to know about hashing passwords, everything you didn't want to know about hashing passwords, and everything you didn't even know you might know about hashing passwords, read How to securely hash passwords?

  • Thank you for the thorough analysis. And for pointing out the concatenation problem.
    – Bobson
    Commented May 8, 2013 at 19:04
  • So first you say that concatenating with the length is bad (invents a new primitive which has not been analyzed by experts) and then later in the answer you recommend "prepend the length". So are you finally advocating for or against it?
    – Ben Voigt
    Commented Mar 16, 2022 at 18:37
  • @BenVoigt I don't understand your question. I don't advocate for concatenating with the length anywhere. I do state that if you need to hash the concatenation of two strings, then you must make it ambiguous, and I do state that one way to make it unambiguous is an encoding involving the length. But 1. this is not necessary here as I've already stated, and 2. the encoding involving the length is not just any concatenation. Commented Mar 16, 2022 at 19:28
  • It's not necessary here because the hash is stored separately -- the system has no ambiguity about where the secret ends and the hash begins, even if there might be ambiguity when looking at the hash function input alone. I'm not sure I believe that there's every a circumstance when the input to the hash function has to contain enough information to decompose it -- the hash function itself is strongly one-way already, so argument preparation composed with hash function will always be a one-way function also.
    – Ben Voigt
    Commented Mar 16, 2022 at 19:52

It depends. If you're using a proper KDF such as PBKDF2 or bcrypt, then there's no benefit whatsoever.

If you're using a simple cryptographic hash function that suffers from length extension attacks (e.g. MD5 or SHA-1) then it may help reduce your susceptibility to such issues. However, at that point, you've got bigger problems.

  • To reinforce the point: use PBKDF2 or bcrypt. Do not roll your own password hashing system. Salting and hashing is not enough. Commented May 8, 2013 at 17:13

I don't see any advantage at all (though no disadvantages either). The purpose of salting is to thwart precomputed hash tables/rainbow tables, forcing the attacker to brute force your hashes instead. If you add an easily computable property of the password in the hashing process, the attacker will just have to do the same as well (for each guessing attempt), and the difference in time will be negligible.

  • I suppose the questions devolves into "Would an easily computable property thwart anything?" For instance, would it make any difference to someone attempting to crack the password based on a list of common passwords & known salt?
    – Bobson
    Commented May 8, 2013 at 16:19
  • @Bobson assuming the attacker knows your hashing protocol (otherwise you get a little additional security by obscurity) I'd say "no". The hash gets a little slower - which is a desirable property when hashing passwords - but as I said the benefit is neglibigle. Better increase the work factor of your hash instead.
    – mgibsonbr
    Commented May 8, 2013 at 16:24

The output of a good hash should be unrelated to the input, thus no additional randomness should be achieved by factoring in the length. The point of the salt isn't to make the hash more unique so much as it is to prevent the possibility of precalculating tables. Since the length of a password being guessed is known, it doesn't add any protection against pre-generated tables.

For example, if we take the salt out of it, testing for password would only ever have to know what password8 is. There would never be a password3 or a password7. The slight obscurity of the algorithm does not have any measurable increase in security.

You must log in to answer this question.

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