"But let’s look at what happens if an attacker discovers a blind SQL injection vulnerability anywhere else in the application.
The attacker doesn’t need to read the database or invert any hashes. An attacker can simply register a legitimate account and generate his own valid API key."
No they can't, The given scenario has not pushed the auth into the database at all. if your accounts are also database accounts why does the user have permission to create new accounts.
I have done this as an experiment, I was dreading building a comprehensive auth system and noticed that the barely used postgres internal auth system is very well fleshed out so just made every user be a database user. The application has little concept of auth at all, it just passes the user login into the database connection and all the auth (logins, what data the user can get, what data the user can write) is all done as database policy. It worked surprisingly well, I don't know if I would use it on a real system(whatever that means, pg logins probably do not scale) The idea still sort of makes my skin crawl, Nobody does it this way, I assume for a reason. But in theory it is fine.
I probably got the idea from the schemaverse game, where the whole game is internal to postgres, and the users are given direct select access.
Its sort of a CORE database feature, the "data control language" - access permissions, schema mapping and object mapping, views abstracting functionality, stored procedures granting RUN AS powers and proxying permissions - they are all very old and well worn tools.
That’s what they do, but the TPM pepper is also needed for HMACing in their threat model.
Otherwise the attacker just adds the victim’s user id to their hashing process too.
TBC, the article isn't about "trust[ing] the database", but about the choice of TCB. There's nothing special about a "database" that makes it more vulnerable than any other API platform.
You're worried about SQL injection attacks? Why are you allowing untrusted clients to do anything other than call stored procedures? They can attack the DB? Why can't they attack the backend?
And sure: cryptographically binding a password to a username in storing a durable credential doesn't hurt, I guess, and it's cheap enough. (But why are you using bearer tokens in the first place?)
My objection is only the tacit assumption in the article that a "database" is some kind of distinct object that somehow accrues special superpowers and vulnerabilities relative to any other kind of service.
A database engine is just one choice of service implementation technology, like Go or Python. A database is just a service. Any service can be insecure.
tl;dr: The author advocates for signing authentication data in the database. Even if an attacker gains write access to the DB and manipulates the auth data, the app can recognize this and prevent access.
I'd rather invest time in writing a proper DB abstraction layer for new systems or audit all parts where the DB is accessed in an existing system than implement the suggested measure.
"But let’s look at what happens if an attacker discovers a blind SQL injection vulnerability anywhere else in the application.
The attacker doesn’t need to read the database or invert any hashes. An attacker can simply register a legitimate account and generate his own valid API key."
No they can't, The given scenario has not pushed the auth into the database at all. if your accounts are also database accounts why does the user have permission to create new accounts.
I have done this as an experiment, I was dreading building a comprehensive auth system and noticed that the barely used postgres internal auth system is very well fleshed out so just made every user be a database user. The application has little concept of auth at all, it just passes the user login into the database connection and all the auth (logins, what data the user can get, what data the user can write) is all done as database policy. It worked surprisingly well, I don't know if I would use it on a real system(whatever that means, pg logins probably do not scale) The idea still sort of makes my skin crawl, Nobody does it this way, I assume for a reason. But in theory it is fine.
I probably got the idea from the schemaverse game, where the whole game is internal to postgres, and the users are given direct select access.
https://github.com/Abstrct/Schemaverse
Its sort of a CORE database feature, the "data control language" - access permissions, schema mapping and object mapping, views abstracting functionality, stored procedures granting RUN AS powers and proxying permissions - they are all very old and well worn tools.
If I have full access to your database I would instead update my org-id and read data from other orgs.
RBAC and proper prepared statements completely defeat all these scenarios.
Why can’t the attacker with db access drop the trigger?
You could (and should) run with minimal permissions which would exclude DDL.
Or just salt the string with the username before hashing.
That’s what they do, but the TPM pepper is also needed for HMACing in their threat model. Otherwise the attacker just adds the victim’s user id to their hashing process too.
TBC, the article isn't about "trust[ing] the database", but about the choice of TCB. There's nothing special about a "database" that makes it more vulnerable than any other API platform.
You're worried about SQL injection attacks? Why are you allowing untrusted clients to do anything other than call stored procedures? They can attack the DB? Why can't they attack the backend?
And sure: cryptographically binding a password to a username in storing a durable credential doesn't hurt, I guess, and it's cheap enough. (But why are you using bearer tokens in the first place?)
My objection is only the tacit assumption in the article that a "database" is some kind of distinct object that somehow accrues special superpowers and vulnerabilities relative to any other kind of service.
A database engine is just one choice of service implementation technology, like Go or Python. A database is just a service. Any service can be insecure.
Great post. Anyone who talks, and actually implements, client key rotation gets a +1 from me.
Far too many systems don’t have a zero downtime key rotation.
tl;dr: The author advocates for signing authentication data in the database. Even if an attacker gains write access to the DB and manipulates the auth data, the app can recognize this and prevent access.
I'd rather invest time in writing a proper DB abstraction layer for new systems or audit all parts where the DB is accessed in an existing system than implement the suggested measure.