Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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.
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).
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.
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.
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.
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/
