Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

migrated from Dec 29 '11 at 21:56

This question came from our site for professional and enthusiast programmers.

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. – Matt Parkins Dec 29 '11 at 16:13
You're right. You did use the word "hashed" a few times. My mistake. Withdrawn. – Bob Kaufman Dec 29 '11 at 16:18
Please see this identical question on a sister site:… 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:… – Jesper Mortensen Dec 29 '11 at 23:27
up vote 2 down vote accepted

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).

share|improve this answer

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.

share|improve this answer
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. – Maarten Bodewes Dec 30 '11 at 19:08
This is a minor advantage: security through obscurity. The added complexity is nothing in the context of crypto. – jcisio Dec 30 '11 at 21:55

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.

share|improve this answer

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.

share|improve this answer

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:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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