To Start, you bring up an excellent point regarding the Pepper issue of a poorly secured salt(aka Cryptographic Key). Also, you are correct that an attacker tha

To Start, you bring up an excellent point regarding the Pepper issue of a poorly secured salt(aka Cryptographic Key). Also, you are correct that an attacker that can get your password DB is usually able to successfully pivot. So here's what I propose: Don't store the key anywhere. Instead, have it be computed from something(s) known and done in a very random and complex manner such that there would be no possible way to decompile release mode code in active execution without triggering a segfault and revealing yourself. See the way you beat a rainbow table is you make the ultimate password large enough to exhaust the practical rainbow table limit since it grows exponentially. So if you do a SHA-256 hash of the password on the client size then you have effectively transformed it into a 64 character password, far larger than any rainbow table could hold. Now it is still susceptible to the direct hash storage in the DB. So I suppose the most secure way is to do it both on the server and on the client. Good Post TaterSolid!