My first read is that 'storing auth data in a relational database is bad' or 'storing critical auth data in a system where only one node can write' is bad, but thinking about the possibilities a bit it could be a factor of data-at-rest as well?
Two factors: the first, that (given the right system permissions) auth data could be fetched from a backup without having access to the system (MySQL/Postgres) directly. Theoretically not a problem if you're salting everything, etc., since you're presumably not storing auth data in plaintext anyway.
Second, no cryptographic verification that nothing has been tampered with? Theoretically possible for someone to e.g. modify the auth data on-disk for the DB to then read and allow auth when it shouldn't.
So I guess at that point the 'solution' would be some form of storage which provides cryptographic verification of its contents so that you can detect tampering, as well as a distributed system with consensus so that if auth data is changed out-of-band then it can be detected and corrected by the other nodes.
You wouldn't store plaintext passwords in a database, right?
For the same reasons you don't want to store keys, tokens or authorization rules either.
Imagine ssh-agent but distributed with eventual consensus. You don't even need transactions, the data model is simple enough that you can get away with eventually consistent CRDT's.
Comments
Storing auth data in MySQL or Postgres is insane and defeats the purpose of trying to be secure.
Note to self: if I ever need a retirement project, open sourcing a properly architected auth solution would be it.
As long as they're salted hashes, they could be stored anywhere right?
Would sqlite be a better option?
Unless you're doing something exceedingly simple, you don't just have hashes, you have things like tokens, keys and authorization rules too.
For the rest of us that have less experience, what is the problem that you're seeing with that? You didn't really make an argument.
My first read is that 'storing auth data in a relational database is bad' or 'storing critical auth data in a system where only one node can write' is bad, but thinking about the possibilities a bit it could be a factor of data-at-rest as well?
Two factors: the first, that (given the right system permissions) auth data could be fetched from a backup without having access to the system (MySQL/Postgres) directly. Theoretically not a problem if you're salting everything, etc., since you're presumably not storing auth data in plaintext anyway.
Second, no cryptographic verification that nothing has been tampered with? Theoretically possible for someone to e.g. modify the auth data on-disk for the DB to then read and allow auth when it shouldn't.
So I guess at that point the 'solution' would be some form of storage which provides cryptographic verification of its contents so that you can detect tampering, as well as a distributed system with consensus so that if auth data is changed out-of-band then it can be detected and corrected by the other nodes.
Correct.
You wouldn't store plaintext passwords in a database, right? For the same reasons you don't want to store keys, tokens or authorization rules either.
Imagine ssh-agent but distributed with eventual consensus. You don't even need transactions, the data model is simple enough that you can get away with eventually consistent CRDT's.
Both have options for column/field level encryption
Besides that, you can encrypt in the app regardless of the data storage
Cool. Now you just have to store the keys somewhere. And figure out how to authenticate/authorize access to them. :)
Sure, but you would have had to do that anyway if you didn't pick those RDBMS and rolled your own storage.
Luckily there's established patterns for key management and access control.
Where else would you store them that's more secure?
if you are a masochist that is a great retirement project!
authn or authz?
You want to keep both in the same place anyways. (Anybody who compromises authz can now compromise authn, and vice-versa.)