Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Don't Trust the Database with Authentication

blog.sturdystatistics.com

Post reply on HN
Print view View original

11–20 of 24 posts

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

#11

Post by hilariously »

somat wrote: post #9

"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 do…

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.

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

#13

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

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

#14

Post by vvanpo »

throwaw12 wrote: post #10

If I have full access to your database I would instead update my org-id and read data from other orgs.

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.

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

#15

Post by 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:

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

#16

Post by vvanpo »

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.

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

#17

Post by vvanpo »

koolba wrote: post #12
tclancy wrote: post #7

Why can’t the attacker with db access drop the trigger?

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.

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

#18

Post by theendisney »

somat wrote: post #9

"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 do…

I hear this before but im no expert.

I recall the moaning long ago that one should never construct sql queries client side.

But it seems you get a luxorious api for free?

I recall people wanting access to order history.

With a bit of code the user could even create their own order process?

It seems if a user has 12 company accounts they could also have an overview db account with read access.

Maybe you can even get rid of the front end entirely :)

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

#19

Post by tclancy »

koolba wrote: post #12
tclancy wrote: post #7

Why can’t the attacker with db access drop the trigger?

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

Sure, but if this person got access to the database, what are the odds they're going to be stuck in a limited role forever?

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

#20

Post by lsaferite »

vvanpo wrote: post #14
throwaw12 wrote: post #10

If I have full access to your database I would instead update my org-id and read data from other orgs.

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?
Post reply on HN