[danudey]

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]

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.