Standard password security involves generating a random salt for each user, somehow combining that salt with their password and hashing them together, and then storing both the hash and sal开发者_运维问答t in the database.
What if, instead of just hash($salt . $password)
, you added in another passphrase as well, stored only in your source code or in a server config file:
$secret_sauce = 'tehB%l1yG*@t$G2uFf'; // perhaps imported from config file
$hash = hash($salt . $secret_sauce . $password);
Does this add any added benefit, or is it just a thin layer of security by obscurity applied to the top?
For password files it would be just a little obscurity added on top.
However, this scheme is called a "keyed hash" and can be used for symmetric (shared-secret) signatures: if you have such a hash, and the input data, then you can be sure that the signature was created by someone who also knows the secret extra bit. Of course, unlike a public-key signature, you cannot verify that without also knowing the secret key.
I'm having trouble tracking down the paper I read a few years ago that suggested it was easy to generate thousands of hash results by partially computing portions of the hash. (As in, by beginning to compute the hash for "foo", you could more easily generate hashes for "foo1", "foo2", "foo3", "foo4", and so on, much cheaper than generating each one individually.)
I think it would argue for salting both before and after a password.
But keep in mind that if the password database can be read by an attacker, they can probably read the salt out of your binary or config file too; it depends on your design.
精彩评论