Why We Don't Trust the Database with Authentication • Hacker News Board

Re: Why We Don't Trust the Database with Authentication

#21

Post by toast0 » Sat, Jul 11, 2026, 3:34 AM UTC

vvanpo wrote: post #17

koolba wrote: post #12

Earlier quoted context omitted.

You could (and should) run with minimal permissions which would exclude DDL.

How many applications actually do, though? At most places I've worked it's common to integrate a schema migration tool (flyway, liquibase) that requires DDL, and I've never seen anyone go to the effort of splitting out an ephemeral instance to run the migration with a separate database connection configuration.

Oof, I never let the application alter the tables. Makes running some applications a giant pain, but DDL should be an administrative thing, not a runtime thing.

Re: Why We Don't Trust the Database with Authentication

#22

Post by mustardo » Sat, Jul 11, 2026, 3:54 AM UTC

vvanpo wrote: post #17

koolba wrote: post #12

Earlier quoted context omitted.

You could (and should) run with minimal permissions which would exclude DDL.

How many applications actually do, though? At most places I've worked it's common to integrate a schema migration tool (flyway, liquibase) that requires DDL, and I've never seen anyone go to the effort of splitting out an ephemeral instance to run the migration with a separate database connection configuration.

Anecdotal but we certainly run flyway migrations with a high privelage user not the regular low privelage "app" user who can only SELECT UPDATE and sometimes DELETE. The fact that nobody does this doesn't mean it's a bad idea just a reflection on poor industry practice (add it to the list)

Re: Why We Don't Trust the Database with Authentication

#23

Post by tybit » Sat, Jul 11, 2026, 6:57 AM UTC

lsaferite wrote: post #20

vvanpo wrote: post #14

Earlier quoted context omitted.

As explained in the article this wouldn't work, because changing your org means your stored hash is no longer valid (as the org is incorporated in the hmac), and you can't generated your own hashes because you're missing the pepper. So after changing your org all subsequent requests would fail.

But logging in gets you a new hash with your new org id, right?

Yeah, if user -> org tenancy is stored in the same database without any similar defence in depth then a fresh API key after updating org would work around this. Would be a interesting topic for them to cover.

I think the same HMAC(pepper, user, org) as a validation column would work. Better yet, encryption with AAD on any tenancy data if you have a TPM available.

Re: Why We Don't Trust the Database with Authentication

#24

Post by LunaSea » Sat, Jul 11, 2026, 9:51 PM UTC

vvanpo wrote: post #16

LunaSea wrote: post #6

RBAC and proper prepared statements completely defeat all these scenarios.

Building an application that is immune to attack defeats all possible attack scenarios, yes. But no application is perfect or immune to all possible attacks, the concept of defense-in-depth is an acknowledgement of this.

Right, but what is presented here is not defense in depth. It's just an additional layer that doesn't address the issue.

The problem at hand is that the PostgreSQL session user has too many access rights and thus the SQL injection is able to wreck havoc.

The presented solution doesn't help because the SQL injection could probably bypass it easily through some other SQL way (custom triggers or rules to intercept the backend pepper or final tokens for example).

The right way to go about this is to create a schema or table per entity combined with authenticating a custom SQL user per customer and setting the RBAC rights for that user correctly.