[hackermom]

Storing the dynamic salt in the same database together with the user's password hash still doesn't tell you HOW the salt is applied or HOW the product has been digested. This requires insight into the login procedure of the application, and this is where the strength of the salt lies. Adding on this security can be done by storing users' salts somewhere else instead of keeping them in the same table and db as the hashes.

My personal method is to work with two salts; one static half (just for the added entropy) kept with the login code, and one dynamic half (always random - not computed from user input) kept in a separate database, away from the hashes. This forces the attacker to acquire not just the database with the hashes, but also the database with the salts, AND the application's login code, in order to get anywhere.

[tptacek]

This is silly. The purpose of a salt (what real cryptographers call a nonce) is simply to make it infeasible to precompute tables. Store it in the open, in the most convenient place possible; don't jump through hoops so you can pretend you're getting more security than you are.

If you really cared about the security of your passwords, you'd use scrypt, bcrypt, or PBKDF2, all of which are markedly more secure than "salted" anything.

[cperciva]

a salt (what real cryptographers call a nonce)

Hmm... not quite. The word "salt" is always used in the context of KDFs. I'm not entirely certain how I'd define the difference between a salt and a nonce, but they feel like subtly different concepts to me.

If you really cared about the security of your passwords, you'd use scrypt, bcrypt, or PBKDF2, all of which are markedly more secure than "salted" anything.

Well, to be fair, scrypt, bcrypt, and PBKDF2 all use salts too. :-)

[tptacek]

Let's be absolutely clear that it is not a clever new use of "salts" that makes PBKDF2, scrypt, or bcrypt more secure; the advantage is in adaptive hashing.

KDFs are a bit of a back-alley in crypto research, and that's the only place the term exists. The argument devolves to whether nonces really are a concept distinct from salts. I'd attempt to win the argument by citing nonces used in ways similar to salts in other crypto protocol settings (there are many).

If you look at PBKDF2, the only reason they call it a "salt" is because they're referring back to the original Unix work, where the term originated.

One way to slice this particular apple is to say that "salt" is a conventional systems design term, and nonce is a cryptosystems term.

This business of calling out "salt" vs. "nonce" as a crypto shibboleth though --- am I just being pedantic? No. Read generalist programmers writing about their idiosyncratic "salt" schemes --- "1/8th of the salt is stored on non-writeable media! 1/4th of it is encrypted with an AES key! 1/2 is stored in the database but XOR's against my mother's maiden name!" --- regardless of the three (3) papers you can cite by real security people using the term, in reality, people talking about "salts" are almost invariably distorting and tangling themselves up in silliness when they really ought to be taking PBKDF2 off the shelf and getting on with their lives.

[cperciva]

KDFs are a bit of a back-alley in crypto research, and that's the only place the term exists.

The term 'salt' also appears in the definition of the PSS signing scheme. And in the HAIFA hash framework. And in some disk encryption schemes.

in reality, people talking about "salts" are almost invariably distorting and tangling themselves up in silliness when they really ought to be taking PBKDF2 off the shelf and getting on with their lives.

Sure. But I maintain that 'salt' is a good word whose reputation has been ruined by the idiots who use it, rather than being inherently a bad word. :-)

[tptacek]

The term "salt" appears only in RSA's web-based tech reports on PSS; the actual Rogaway paper calls them "seeds".

Have to concede Biham's HAIFA paper to you.

[cperciva]

The term "salt" appears only in RSA's web-based tech reports on PSS

Fair enough. But let's face it, people RFC 3447, not the original paper.

[sp4rki]

+1 scrypt, bcrypt, or PBKDF2

You saved me some typing there! Anyways I concur.