> Suppose they just have a SQL injection ....

But what about having separate auth sub-service with separate database.

Who says a SQL injection allows yourself to update your account to be admin. (SQL has their own permission system even through its not used that much).

Who says making yourself application admin allows yourself to do more then banning users.

Sure for many especially smaller systems pepper won't help much and AD (additional data) is even less likely to help.

But for many (especially bigger/enterprise) systems this might very well not be the case.

Furthermore pepper usage tend to not really hurt.

I think it's a fallacy to assume just because many less well build systems allow SQL injection to escalate that all do so and pepper is useless. Especially given that most systems need to have some config secret management system anyway and as such adding a pepper tend to be somewhat cheap to to (dev effort) and doesn't really cost much at runtime either (normally).

> But what about having separate auth sub-service with separate database.

Sure, my point was mainly about classic monolithic apps. If you split your app up into lots of separate micro-services, my point may no longer hold.

> Who says a SQL injection allows yourself to update your account to be admin.

I wasn't talking about a database superuser account, I was talking about an application-level admin. Usually there is some database table which stores user permissions, and an attacker can do an UPDATE/INSERT on that table to grant an ordinary user account full admin permissions, or even create a brand new user with those permissions. All this can happen within the single ordinary DB account used by the application (given most applications only use one DB account)

> 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.

Admin tools should probably be IP whitelisted instead than open to the world if admins are few?

Then the attacker will just add their ip to the whitelist?

Is that not the default? Err on the side of better security?

Yes, furthermore (db) admin login should preferable be done over a different SQL user so that a normal usages SQL injection can never be used to update anyone to have any admin rights.

But then just giving the default user admin rights can make many (not so good but widely used) deployment tools and methodologies and similar much easier to use so you see it quite often.

I have seen it a few times. Default db user being a db admin because the ad-hoc written deployment script during initial development was never updated and security didn't matter back during per-release bootstrapping. ;=(

> Yes, furthermore (db) admin login should preferable be done over a different SQL user so that a normal usages SQL injection can never be used to update anyone to have any admin rights.

You have to distinguish application admin rights from DB admin rights. Most apps run with an ordinary DB user account, and even with a SQL injection bug in the app, you'd need to find an additional database vulnerability to upgrade the ordinary DB user account to a DB admin account.

However, for most apps, what is really valuable is the data, not the database, and for the data you don't need the DB admin account. The app's own users are often stored in a database table, with some flag (or something more complex like a separate group membership table) used to give an app user admin rights in the application. The point is, those admin rights can potentially unlock maintenance-focused features which could be used to extract the password pepper from the configuration. (Of course, as other commenters have pointed out, this is much harder in a microservices architecture with a user authentication service than in a classic monolithic app.) Giving a user admin access via SQL injection can also have other benefits – while data theft can be done via a SQL injection vulnerability, it can be cumbersome; using REST APIs, file export screens, etc, can potentially make data theft quicker and easier. The cost is increased risk of discovery, since auditing of admin rights may discover some unexpected new user granted admin rights, or some existing user having them unexpectedly – by contrast, data theft via a pure SQL injection with no data changes made would not be detected by an access audit.