> There are many attack scenarios in which storing a secret separate from the DB doesn't get you much at all. Suppose an attacker finds an RCE vulnerability in the application – then they can slurp up the contents of the DB, but they can read the pepper from the configuration too.
If the auth is a service accessing only via some remote access protocol that only allows a minimum number of operations that do not map directly into database commands they cannot exploit RCE in the app to get auth database.
Such service can also enforce reasonable rate limits and quotas, something that a regular direct database access can't enforce.
It's really hard to store pepper in a system meaningfully more secure than the password hashes themselves. For any suggestion of a safer way to store pepper my response is "store the password hashes there instead". Until you get to the point of decrypting password hashes in a TPM I don't see any benefit and at that point you've switched to a hardware solution.
That's not the argument though - the argument is that storing high security rarely accessed information ( hashes of passwords / encrypted passwords ) that are needed for a very limited number of well defined operations on the same system within the same security domain with the low security often accessed information with a high number of not well defined operations is what responsible for majority of hashed/encrypted credential leaks anyway.
You are going to have a much harder time getting data from a service that only speaks HTTPs with 6 endpoints that can only be fed 1 type of JSON with only specific fields present per end point rate limited to rates per second that make sense for those individual end points with a database backing it being internal to that service which gets 15 deploys per year than from a Gigantic Database Supporting Application That Does Everything For Users and Business and Marketing and Analytics that keeps changing based on weekly sprints.
If the auth is a service accessing only via some remote access protocol that only allows a minimum number of operations that do not map directly into database commands they cannot exploit RCE in the app to get auth database.
Such service can also enforce reasonable rate limits and quotas, something that a regular direct database access can't enforce.