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 p

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 https://www.freebsd.org/cgi/man.cgi?query=crypt%283%29 or http://man7.org/linux/man-pages/man3/crypt.3.html 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