Why We Don't Trust the Database with Authentication
I explain why treating the database as the ultimate source of truth for API authentication is a critical vulnerability. At Sturdy Statistics, we use Defense in Depth by cryptographically binding keys to tenant contexts using a server-side pepper. This ensures that even if an attacker compromises the database via SQL injection, they cannot forge valid credentials or bypass tenant boundaries, keeping our system secure.
The database no longer decides identity on its own; it stores verifiers that only the backend can validate.
- mamcx
> When writing an API, it’s easy to unknowingly introduce a dangerous, implicit assumption: that the database is the ultimate source of truth. If a record is in the database, an application often treats it as authoritative. I want to explain in this post why that might be a very bad idea.
This premise is weird at best.
"the database is the ultimate source of truth" is not a "dangerous, implicit assumption", is the best rule you can get (and the rest of the post say so: all useful data comes from it!)
Instead the rest of the article is interesting on how to choose what to use for the hash, but not follow with this first paragraph :shrug:
- vvanpo
A pepper is just a salt that is "secret", i.e. not stored next to the hashes being salted. It indeed provides the desired defense-in-depth, in that a breach of the database does not allow spoofing requests to the application; a successful attack would require both an exploit giving database access as well as an exploit exposing the secret pepper. But this is just a result of splitting state across multiple data stores---you could theoretically split data across n databases which would require an attacker to find n exploits. As such I don't fully agree with their conclusion that "database state alone should not be able to grant authentication": just because you store application-wide secrets elsewhere doesn't mean it's not part of the application state, and isn't stored in a database.
For most monolithic applications I think the whole issue is be a bit moot; if the rest of the application state is in the primary database, then an attacker with database access could presumably accomplish anything without the need to spoof another user at the authentication layer.
Lastly, this scheme doesn't provide any mechanism for rotating the pepper.
- throwaw12
If I have full access to your database I would instead update my org-id and read data from other orgs.