> Say a programmer on your team accidentally pushes code that makes your salt a static value for all users going forward

This should fail an obvious unit test for the password handling code. The obvious unit tests for this component include a check that minting two password hashes for the same password gives different results.

You've never seen someone break or add a @ignore to a unit test they don't understand in order to push out some code? Unfortunately I have, either way that isn't the only situation where a pepper is useful.

I've never reviewed such a change. If I saw it I guess it would be one of the rare cases where rather than either writing LGTM or asking some questions and giving approval conditional on getting acceptable answers (or revised code that obviates the questions), I would just press "Reject".

If people are going to be allowed to meddle with security critical code with no effective oversight you're already dead you just didn't know it yet. They can go modify the password checking code to return true because that seems to "work better" and if nobody rejects that you no longer have password authentication.

I've never reviewed such a change but I've fixed bugs where a test that would've caught the bug was ignored because it caused the build pipeline to fail. My guess the programmer was on a tight deadline and had to ship it so they cut a corner and forgot to get back to it. That's the reality of many if not most organizations, good software engineering is a afterthought compared to the concerns of keeping the lights on day to day. As such I have changed my personal operational model and include as many cheap safeguards as I can when I'm doing something important. This is just one of those things I have in my anti-footgun bag of tricks.

Your pepper is always static, and your salt becomes static. Wouldn't that essentially be peppered even without the pepper?

I don't see any value of a pepper. It doesn't actually add any protection.

No, because the static salt will be stored in the database alongside the passwords. The pepper would be compiled and live in the application layer. The value is minimal but so is the cost.

If it's static salt, it breaks the use of salt. Salt was designed such that a rainbow table cannot crack two similar passwords based on hash, exactly what a static salt would facilitate.

If not stored in the database, it ensures that a database dump alone isn’t enough to recover even a single password. It certainly doesn’t have the level of impact that salting passwords or using a cpu-hard and memory-hard hash does, but it’s certainly something.

Modern password hashes like argon2 include this feature natively.