Currently, sensitive authentication data (passwords, user tokens, 2FA secrets etc) is stored the same way any other data is, which makes it vulnerable to stealing via injection attacks. This is a known problem (T122375: Segment sensitive data within WMF cluster (tracking)); the plan used to be move it into a separate service (T140813 / T120484), but that got deprioritized, is not on the roadmap anymore, and IMO has a bad cost/benefit ratio anyway (also does not do anything about fixing the issue in standalone MediaWiki).
Instead, we could do segmentation on a budget:
- store all authentication data in a separate table (or set of tables), with a separate DB user to read/write it; make sure the "usual" DB users ($wgDBuser etc) do not get access to it
- define a separate auth-tables-only loadbalancer service (same as DBLoadBalancerFactory just with different user/password)
- code that accesses auth data has to use DAO classes; only those classes can access the auth-tables-only loadbalancer service (easy to ensure via CI, or just code review).
That would drastically reduce the security review surface for SQL injection, to the point of practically eliminating that threat. It wouldn't offer much defense against remote code execution, but that's not really feasible to defend against, anyways.