Salting Your Password: Best Practices?

Question

I've always been curious... Which is better when salting a password for hashing: prefix, or postfix? Why? Or does it matter, so long as you salt?

To explain: We all (hopefully) know by now that we should salt a password before we hash it for storage in the database [Edit: So you can avoid things like what happened to Jeff Atwood recently]. Typically this is done by concatenating the salt with the password before passing it through the hashing algorithm. But the examples vary... Some examples prepend the salt before the password. Some examples add the salt after the password. I've even seen some that try to put the salt in the middle.

So which is the better method, and why? Is there a method that decreases the chance of a hash collision? My Googling hasn't turned up a decent analysis on the subject.

Edit: Great answers folks! I'm sorry I could only pick one answer. :)

Answer 1

It shouldn't make any difference. The hash will be no more easily guessable wherever you put the salt. Hash collisions are both rare and unpredictable, by virtue of being intentionally non-linear. If it made a difference to the security, that would suggest a problem with the hashing, not the salting.

Answer 2

Prefix or suffix is irrelevant, it's only about adding some entropy and length to the password.

You should consider those three things:

1. The salt has to be different for every password you store. (This is quite a common misunderstanding.)
2. Use a cryptographically secure random number generator.
3. Choose a long enough salt. Think about the birthday problem.

There's an excellent answer by Dave Sherohman to another question why you should use randomly generated salts instead of a user's name (or other personal data). If you follow those suggestions, it really doesn't matter where you put your salt in.

Answer 3

BCrypt hash if the platform has a provider. I love how you don't worry about creating the salts and you can make them even stronger if you want.

Answer 4

I think it's all semantics. Putting it before or after doesn't matter except against a very specific threat model.

The fact that it's there is supposed to defeat rainbow tables.

The threat model I alluded to would be the scenario where the adversary can have rainbow tables of common salts appended/prepended to the password. (Say the NSA) You're guessing they either have it appended or prepended but not both. That's silly, and it's a poor guess.

It'd be better to assume that they have the capacity to store these rainbow tables, but not, say, tables with strange salts interspersed in the middle of the password. In that narrow case, I would conjecture that interspersed would be best.

Like I said. It's semantics. Pick a different salt per password, a long salt, and include odd characters in it like symbols and ASCII codes: ©¤¡

Answer 5

Inserting the salt an arbitrary number of characters into the password is the least expected case, and therefore the most "secure" socially, but it's really not very significant in the general case as long as you're using long, unique-per-password strings for salts.

Answer 6

If using a cryptographically secure hash, it shouldn't matter whether you pre- or postfix; a point of hashing is that a single bit change in the source data (no matter where) should produce a different hash.

What is important, though, is using long salts, generating them with a proper cryptographic PRNG, and having per-user salts. Storing the per-user salts in your database is not a security issue, using a site-wide hash is.

Answer 7

Hypothetical threat model:

The attacker has 'rainbow tables' consisting not of the hashes of dictionary words, but of the state of the hash computation just before finalising the hash calculation.

It could then be cheaper to brute-force a password file entry with postfix salt than prefix salt: for each dictionary word in turn you would load the state, add the salt bytes into the hash, and then finalise it. With prefixed salt there would be nothing in common between the calculations for each dictionary word.

I assume of course that the hash computation uses the bytes in order, but that's not uncommon. If the hash were reverse-order, you'd want postfix salt, but I don't know that any normal hash does that. Crucially, the threat doesn't apply if the hash computation works on blocks so large that the trial passwords don't fit in one, because then you couldn't usefully do a part-computation using a dictionary word. "Proper" cryptographic hashes like MD5 and SHA-anything fall into this category, so I don't think it's a practical concern.

I just made up this threat model - I don't actually know what experts say on the subject, except that on page 52 of 'Applied Cryptography' Schneier arguably implies that salt should be prefixed, since he describes it as 'a simple attempt at an initialization vector'.

The hypothetical 'rainbow table' might of course be much bigger than a regular one, and the attack much slower than a regular reverse-hash lookup. But it would be some linear factor faster than a regular brute force. Since regular brute forcing does in practice crack "weak" passwords in achievable time, an improved brute force would change the definition of "weak", raising the bar for how good your passwords need to be.

Answer 8

First of all, the term "rainbow table" is consistently misused. A "rainbow" table is just a particular kind of lookup table, one that allows a particular kind of data compression on the keys. By trading computation for space, a lookup table that would take 1000 TB can be compressed a thousand times so that it can be stored on a smaller drive drive.

You should be worried about hash to password lookup tables, rainbow or otherwise.

@onebyone.livejournal.com:

The attacker has 'rainbow tables' consisting not of the hashes of dictionary words, but of the state of the hash computation just before finalising the hash calculation.

It could then be cheaper to brute-force a password file entry with postfix salt than prefix salt: for each dictionary word in turn you would load the state, add the salt bytes into the hash, and then finalise it. With prefixed salt there would be nothing in common between the calculations for each dictionary word.

For a simple hash function that scans linearly through the input string, such as a simple linear congruential generator, this is a practical attack. But a cryptographically secure hash function is deliberately designed to have multiple rounds, each of which uses all the bits of the input string, so that computing the internal state just prior to the addition of the salt is not meaningful after the first round. For example, SHA-1 has 80 rounds.

Moreover password hashing algorithms like PBKDF compose their hash function multiple times (it is recommended to iterate PBKDF-2 a minimum of 1000 times, each iteration applying SHA-1 twice) making this attack doubly impractical.