5
$\begingroup$

Assuming that the salts are sufficiently long (16 random chars) is there any advantage in using a per-application salt in addition to a per-secret salt when storing hashed passwords in a database?

The per-application salt would held in the code. The per-secret salt would be held in plain text on the same database entry as the hashed password.

$\endgroup$
3
  • 2
    $\begingroup$ Bob, I think I was fairly clear that I'm storing a hash of a password - the whole question is related to how I should go about hashing that password before disgarding it. $\endgroup$
    – Matt Parkins
    Dec 29, 2011 at 16:13
  • $\begingroup$ You're right. You did use the word "hashed" a few times. My mistake. Withdrawn. $\endgroup$
    – Bob Kaufman
    Dec 29, 2011 at 16:18
  • 1
    $\begingroup$ Please see this identical question on a sister site: security.stackexchange.com/questions/3272/… Also, about the "how I should go about hashing" part: It sounds like you might perhaps be making up your own password hashing scheme. Please don't, use an existing peer reviewed method for password storage instead: security.stackexchange.com/questions/211/… $\endgroup$
    – user950
    Dec 29, 2011 at 23:27

5 Answers 5

2
$\begingroup$

The usual assumption made when designing a password hashing scheme is that, if an attacker can read your database, they probably can read your code and config files too.

Of course, this may not always be the case: for example, an SQL injection attack might compromise your database without giving the attacker filesystem access. But it does hold in many other cases, and in general, it's never a good idea to assume that an attacker will be less capable than they might be.

So, adding a secret per-application component (sometimes called "pepper") to the salt may improve security in some situations. But you shouldn't assume that it will, which means that you should design your hashing scheme to be as secure as possible even if the attacker knows the pepper. Once you've done that, whether or not you still want to bother with the pepper is up to you.

One thing using pepper can help you with, which is difficult to achieve by other means, is protecting your users from their poor password choices. If a user chooses a very common or easily guessable password, like "abc123" or "letmein" or their own username backwards, and if an attacker manages to access the password database and mount an offline attack on it, no practical amount of salting or key stretching is going to keep the attacker from guessing the password. However, if your password hashes contain a secret key which the attacker hasn't managed to obtain, the database is useless for them and they're reduces to on-line attacks against your application (and thus subject to rate-limiting, which you've hopefully implemented).

$\endgroup$
5
$\begingroup$

There is an advantage.

Cracking a password from its hash without knowing the salt is extremely difficult, as you're essentially increasing the password length by the length of the salt.

If you're storing the hash in such a way that it isn't obvious that it's been salted by the application, the attacker likely won't go looking for it. If the application itself isn't plain text (ie; compiled in some way), even if they do go searching for it, it is non-trivial to find.

$\endgroup$
2
  • $\begingroup$ Very interesting, basically you make the salt a key. Of course, you would need to treat it in the same way (regarding backup, secrecy etc) to use this to the full effect. You could hard code it, but if the code has similar access at the database you will just obfuscate the salt value. $\endgroup$
    – Maarten Bodewes
    Dec 30, 2011 at 19:08
  • 3
    $\begingroup$ This is a minor advantage: security through obscurity. The added complexity is nothing in the context of crypto. $\endgroup$
    – jcisio
    Dec 30, 2011 at 21:55
3
$\begingroup$

Not really. Hash salts are generally used to protect against rainbow table and dictionary attacks. If you have a random salt for each secret, you're protecting each hash against such an attack. An application-level salt might theoretically add some complexity to matching a hash, but any difficulty it adds would be linear, which in the context of crypto does not change anything.

$\endgroup$
2
$\begingroup$

There is a security advantage, although it's up to you to decide if it's worth it.

Without the salt(s) , a password can't be verified against the stored hash, meaning it can't be brute-forced. If an attacker compromises the entire system then she has both the salt from the db and from the application code. But a common attack vector - SQL injection - gives access to the DB only. In the face of this attack the application salt remains secret and the passwords unrecoverable by the attacker.

$\endgroup$
1
$\begingroup$

The aim of hashing is to make it difficult to crack passwords using brute force and rainbow tables. Using per-secret salt should be sufficient if you are using sufficiently long salt (which I see you are). Using per-application salt will not add much to the reversibility of the hashed password other than adding a bit of obfuscation and obviously increasing the effective length of your password. So, the password that could be brute forced in say 100 years will now take 10000 years.

You should be fine with a per-secret salt. However, make sure that you hash it multiple times or prefably use bcrypt to hash it. Refer this article: http://codahale.com/how-to-safely-store-a-password/

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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