As mentioned by someone else in the thread [0], Dropbox is using pepper with encryption. Many (stupid) people will use it with hashing instead, which means they cannot rotate the pepper without resetting every user's password.

Moreover, using pepper will make some (stupider) people do stuff like

  hash( salt + hash( pepper + password ) )

which is very likely to increase the attack surface.

More broadly, since most secure hashing functions were not designed to be used pepper, it forces people to try to come up with their own ways of making it work. They should not: DO NOT roll your own crypto [1].

[0] https://news.ycombinator.com/item?id=12548597

[1] https://www.schneier.com/blog/archives/2011/04/schneiers_law...

What's the problem with `H(salt||H(pepper||password))`? If `H` is a good PRF, it should work fine (you want `KDF(salt, H(pepper||password))` to protect against guessing attacks).

In any case, if you pepper is exposed and you don't have a good pepper rotation scheme, you are no worse than if you started with no pepper at all.

Are they stupid people, or just uneducated? (Stupid implies they can never correct that behavior)

The uneducated but not stupid developer would not write her own password storage system.

What wrong with concatenating the pepper with the password, other than it not allowing easy pepper rotation?

Nothing

If the used hash function is based on the Merkle-Damgård construction, then it is vulnerable to a length extension attack [1]. That means if an attacker knows a hash of the form H(pepper || salt || password), then the attacker can generate more hashes H(pepper || salt || password || password_extension) by only knowing the combined length of pepper, salt and password but without knowing any of the values. That does not help breaking the password but you still have an attack point in your system. Maybe someone makes a really bad decision and decides to reuse the password hash for something it really should not be used. Also note that with this construction you can trivially find collisions for different pepper, salt and password, they just have to yield the same string when concatenated.

Okay, but the suggestion was not to just concatenate everything but involved hashing parts before further concatenating and hashing them again. The length extension attack will still apply, you could for example use it on H(pepper || password) in H(salt || H(pepper || password)). Is this useful? Where would you get the length of and a hash for pepper || password from? I don't know but why would you risk that someone figures out how to do and abuse it if there are alternatives? And last but not least constructions like H1(H2(message)) or H1(message) || H2(message) may look innocent but they are not and they may weaken your system. See for example this Cryptography Stack Exchange question [2] or the answer by ircmaxell on this Stack Overflow question [3].

[1] https://en.wikipedia.org/wiki/Length_extension_attack

[2] http://crypto.stackexchange.com/questions/270/guarding-again...

[3] http://stackoverflow.com/questions/348109/is-double-hashing-...

So as a couple comments ask, what if you have to rotate the pepper? There's ways to do that, but sometimes people disengage their brains, and by making the whole scheme a little more complicated and a little more difficult to work with, you entice people to cheat. Like storing the plaintext password in a second column for "rehashing" purposes.

If you encrypt instead of peppering, you just decrypt then re-encrypt with a new key and call it a day.

Peppering has always meant, to me, doing something like this:

  // Hashing
  $preHash = base64_encode(
      hash_hmac('sha512', $password, $_ENV['pepper'], true)
  );
  $storedHash = password_hash($preHash, PASSWORD_DEFAULT);

  // Validation
  $preHash = base64_encode(
      hash_hmac('sha512', $password, $_ENV['pepper'], true)
  );
  if (password_verify($preHash, $storedHash)) {
      // You're in!
  }

To anyone reading this: Don't bother peppering.

Alternatively you could just encrypt the already encrypted data with the new key.

Wouldn't that require you to retain all compromised keys, and daisy chain the encryption operations?