Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

Code:
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.

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

4 Answers

up vote 4 down vote accepted

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?

share|improve this answer
    
Thank you for the thorough analysis. And for pointing out the concatenation problem. –  Bobson May 8 '13 at 19:04
add comment

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.

share|improve this answer
    
To reinforce the point: use PBKDF2 or bcrypt. Do not roll your own password hashing system. Salting and hashing is not enough. –  Stephen Touset May 8 '13 at 17:13
add comment

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.

share|improve this answer
    
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 May 8 '13 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 May 8 '13 at 16:24
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.