In a general sense, concatenating a pepper with your salt is NOT reinventing anything at all. (You can rephrase that as "Store pieces of your salt in separate places" which doesn't change or violate any traditional, rigorously tested application of salt in cryptography)

There are issues with using it as implemented in some posts here, with nested bcrypts, to be sure, but I think the concept is still fairly sound, though there are certainly implementation pros and cons.

----

As for maintainability:

I'm also familiar with crypt(3)-style password hashes, where a prefix uniquely specifies the algorithm (and subvariant) used.[1]

Why wouldn't this be fitting here? You can then easily detect, and deal with, passwords that have been tagged with "previous" peppers, such as forcing returning users to change password if a previous pepper was compromised, etc.

1 https://www.freebsd.org/cgi/man.cgi?query=crypt%283%29 or http://man7.org/linux/man-pages/man3/crypt.3.html, for some reason I can't find a link to a more comprehensive list at the moment

By that logic, every extra character you concat onto a salt is also "rolling your own crypto."

For example if my salt was CrytoRandom(10), and you increase it to CrytoRandom(15) you've just "rolled your own crypto" according to you.

If that is not the case then explain the difference between CryptoRandom(15) and CrytoRandom(10) + CryptoRandom(5) (longer salt Vs. salt+pepper).

There's a lot of people spreading FUD ("it is unknown!!!") and nonsense (concat two strings is literally rolling your own crypto!) in this thread.

I don't know if peppers are worth the dev' time, deployment issues, and additional maintenance (e.g. rotation). However I do know that the people arguing against it here aren't making rational counter-arguments that hold up under basic scrutiny.

I'm no security expert, but there are some obvious problems with concatting salt + pepper. For example, most hash libraries include the salt in the output so that you only have to store a single string (also encoded in the output would be the hash algorithm and a few input parameters). So now you've likely revealed your pepper in the DB. Oops! So much for extra security.

But that's not all! Hash algorithms are written assuming the salt is random, and now I have millions of hash outputs in which the last X bytes of the salt are shared. Have you proven that this doesn't increase the attack surface? It certainly sounds like it might. This is exactly the type of side-channel attack that tends to break crypto, and you're giving it away for free.

PBKDFs like bcrypt assume the salt is a random value that is not re-used and is not required to be secret. You are re-using part of it, and require that it is secret. That's the worrying part, and it's one of the reasons that several concrete proposals posted here have actual security flaws.

Maybe. But that only makes sense if you reduce the length of the salt to add the pepper, which nobody is suggesting.

If the salt remains the same length and you add the pepper on top, it won't make the final hash less secure/strong, due to the way hashing algorithms are folded.

At worst case scenario you've literally added no security at all with the pepper. There's no rational scenario where it reduces the security when all other things remain equal (i.e. you aren't replacing the salt with a pepper, or reducing the salt's length/complexity for the pepper, etc).

> At worst case scenario you've literally added no security at all with the pepper.

Yes, I think this is the most likely failure mode (though not necessarily the only one - crypto can fail in very suprising ways!).

But even this is harmful, since you are potentially making changes to security-critical code for no benefit. At best you get more complexity and more chances to introduce bugs, plus a false sense of security.