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.
Note to self: if I ever need a retirement project, open sourcing a properly architected auth solution would be it.
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.
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.
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. :)
Luckily there's established patterns for key management and access control.