Password Hashing add salt + pepper or is salt enough?

Question

Please Note: I'm aware that the proper method for secure password storage hashing is either scrypt or bcrypt. This question isn't for implementation in actual software, it's for my own understanding.

Related

• How to securely hash passwords?
• HMAC - Why not HMAC for password storage?
• How to apply a pepper correctly to bcrypt?

---

Background
As far as I know, the recommended/approved method for storing password verifiers is to store:

$verifier = $salt + hash( $salt + $password )

Where
  hash() is a cryptographic hashing algorithm
  $salt is a a random, evenly distributed, high entropy value
  $password is the password entered by the user

Some people advice to add a secret key into the mix (sometimes called 'pepper'). Where the pepper is a secret, high entropy, system-specific constant.

The rationale seems to be that the it even if the attacker gets hold of the password verifiers, there is a good chance he or she does not know the pepper value. So mounting a successful attack becomes harder.

So, my question is:
Does adding a pepper value in addition to a salt when hashing passwords increase the overall security?

Or is the perceived increased security based on false assumptions?

Quick Update
I know the purpose of the $salt (I wrote quite a long answer on stackoverflow about it) the additional $pepper key is not  improving upon what the salt does.
The question is, does the $pepper add any security other than what the salt does.

Answer 1

(Note: using a salt is only half of the job; you also need to make the hash function slow -- so that attacking a single low-entropy password is still difficult. Slowness is usually achieved through multiple iterations, or hashing the concatenation of 10000 copies of the salt and password.)

What your "pepper" does is that it transforms the hash into a MAC. Making a good, secure MAC out of a hash function is not easy, so you'd better use HMAC instead of a homemade construct (the theoretical way of putting it is that a collision-resistant hash function is not necessarily indistinguishable from a random oracle).

With a MAC, you may gain some security in the following sense: possibly, database read access by the attacker could cease to be a real problem. The MAC key (the "pepper") may concentrate the confidentiality need. However, this relies on the MAC being also a one-way function, which is a property which you will get from many MAC constructions (including HMAC) but which is not really guaranteed cryptographically speaking (there are subtleties).

The "pepper" implies that you have a key to manage, including secure storage in a way which resists to reboots. A key is small and fits in RAM, but, due to the storage requirements, it is unclear whether it actually improves security. An attacker who can read the whole database usually can also read the whole harddisk, including any "protected" file. The key small size may allow for some advanced setups, e.g. the key being stored on smartcards which are used at boot time but not left connected afterwards. To sum up, whether peppering is worth the effort thoroughly depends on the context -- on a general basis, I would recommend against it, in order to avoid the added complexity.

Answer 2

In some circumstances, peppers can be helpful. (This answer is marked Community Wiki. Feel free to edit.)

As a typical example, let's say you're building a web application. It consists of webapp code (running in some webapp framework, ASP.NET MVC, Pyramid on Python, doesn't matter) and a SQL Database for storage. The webapp and SQL DB run on different physical servers.

The most common attack against the database is a successful SQL Injection Attack. This kind of attack does not necessarily gain access to your webapp code, because the webapp runs on a different server & user-ID.

You need to store passwords securely in the database, and come up with something on the form of:

$hashed_password = SHA512( $salt . $password )

where $salt is stored in plaintext in the database, together with the $hashed_password representation.

(I'm just using SHA512 as an example, assume that a few interations of any crossplatform cryptographic hash might have been used, i.e. MD5, SHA-family, etc. Actually, as noted below, a computationally expensive solution should be preferred.)

The question is then, given that it is almost zero effort to add a constant value to the application code, and that the application code will typically not be compromised during an SQL Injection Attack, is the following then substantially better than the above?

$hashed_password = SHA512( $salt . $pepper . $password )

where $salt is stored in plaintext in the database, and $pepper is a constant stored in plaintext in the application code.

Adding this $pepper is easy -- you're just creating a constant in your code, entering a large random value into it, and using that constant in the password hashing function. If you have existing users you need a migration strategy, but this is relatively easy because regardless of which hash function you use, you can add a hash with the pepper at the end.

Answer:

Using the $pepper does add to the strength of the password hash when compromise of the database does not imply compromise of the application.

But whether or not adding a $pepper is appropriate for your situation, you should always be sure that your cryptographic hash isn't too efficient and use e.g. scrypt or bcrypt.

Answer 3

The paper on the invention of salting and iterations, for Unix passwords (Password Security: A Case History, Morris & Thompson, 1978), also described the equivalent of a pepper:

The first eight characters of the user’s password are used as a key for the DES; then the algorithm is used to encrypt a constant. Although this constant is zero at the moment, it is easily accessible and can be made installation-dependent.

I haven't heard of it being used though. Has anyone else?

Answer 4

I would like to point out what a pepper really can do.

When does a pepper help?

As the others already pointed out, adding a pepper is only an advantage, as long as the attacker has access to the hash-values in the database, but has no control over the server, and therefore does not know the pepper. This is typical for SQL-injection, probably one of the more often used attacks, because it is so easy to do.

What does a pepper improve?

$hashValue = bcrypt('12345', $cost, $salt);

This password you can get easily with a dictionary attack, even if you correctly used a slow key-derivation function. Put the most used passwords into a dictionary and brute force with this weak passwords. It's very likely that we find the password in (too) many cases.

$hashValue = bcrypt('12345anm8e3M-83*2cQ1mlZaU', $cost, $salt);

With the pepper, the weak password grows in length, it contains now special characters, and more important, you will find it in no dictionary. So, as long as the pepper stays secret, it does prevent dictionary attacks, in this case it can protect weak passwords.

Edit:

Often it is recommended to combine password and pepper with a hmac. In both cases the pepper fulfills its job as long as it stays secret. When it becomes known, neither will give any advantage.

$pepperedPassword = hash_hmac('sha256', '12345', 'anm8e3M-83*2cQ1mlZaU');
$hashValue = bcrypt($pepperedPassword, $cost, $salt);

One should be careful, that the result of the hmac is not binary output, because a bcrypt implementation could stumble over a null byte in the peppered password.