[benhirashima]

from wikipedia: "A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. The attacker has access to both the encrypted password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password."

[benhirashima]

one strategy that has occurred to me is to use a secret "master" salt, in addition to random public salts for each password. that way, an attacker would have to obtain the secret salt, as well as the public salts. the secret salt would be stored in the program that does the hashing, and not in the database. this requires an attacker to gain access to the filesystem where the program lives, as well as the database. of course, this offers no guarantees, but does make it harder for the attacker.

[shabble]

I think this occurs to nearly everyone. It's commonly referred to as a "pepper"[1], and is generally considered not all that helpful in most scenarios, as well as being potential evidence that you're a witch^W^WDoing Your Own Crypto, which is bad.

[1] See towards the end of the very comprehensive first answer. http://security.stackexchange.com/questions/211/how-to-secur...

Then go back, read the rest of it :)

[benhirashima]

thanks for the link. it was a good read. however, i see nothing in there that suggests that using a pepper is necessarily a bad thing.

i think the answer from rory mcclune puts it well: "Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database."