3 ms·

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 sourci

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.

exographicskip 11mo ago
As long as they're salted hashes, they could be stored anywhere right? Would sqlite be a better option?
- otabdeveloper4 11mo ago
  > As long as they're salted hashes, they could be stored anywhere right? Unless you're doing something exceedingly simple, you don't just have hashes, you have things like tokens, keys and authorization rules too.
ilkhan4 11mo ago
Where else would you store them that's more secure?
esafak 11mo ago
authn or authz?
- otabdeveloper4 11mo ago
  You want to keep both in the same place anyways. (Anybody who compromises authz can now compromise authn, and vice-versa.)
mariusor 11mo ago
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.
- danudey 11mo ago
  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.
  - otabdeveloper4 11mo ago
    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.
vinckr 11mo ago
if you are a masochist that is a great retirement project!
nijave 11mo ago
Both have options for column/field level encryption Besides that, you can encrypt in the app regardless of the data storage
- otabdeveloper4 11mo ago
  > Both have options for column/field level encryption Cool. Now you just have to store the keys somewhere. And figure out how to authenticate/authorize access to them. :)
  - nijave 11mo ago
    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.

exographicskip 11mo ago

As long as they're salted hashes, they could be stored anywhere right? Would sqlite be a better option?

otabdeveloper4 11mo ago
> As long as they're salted hashes, they could be stored anywhere right? Unless you're doing something exceedingly simple, you don't just have hashes, you have things like tokens, keys and authorization rules too.

ilkhan4 11mo ago

Where else would you store them that's more secure?

esafak 11mo ago

authn or authz?

otabdeveloper4 11mo ago
You want to keep both in the same place anyways. (Anybody who compromises authz can now compromise authn, and vice-versa.)

mariusor 11mo ago

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.

danudey 11mo ago
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.
- otabdeveloper4 11mo ago
  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.

vinckr 11mo ago

if you are a masochist that is a great retirement project!

nijave 11mo ago

Both have options for column/field level encryption Besides that, you can encrypt in the app regardless of the data storage

otabdeveloper4 11mo ago
> Both have options for column/field level encryption Cool. Now you just have to store the keys somewhere. And figure out how to authenticate/authorize access to them. :)
- nijave 11mo ago
  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.