* Robert Haas (robertmh...@gmail.com) wrote: > On Sun, Feb 19, 2017 at 6:13 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: > > On Sun, Feb 19, 2017 at 8:03 PM, Magnus Hagander <mag...@hagander.net> > > wrote: > >> If password auth is used, we have to store the password in plaintext > >> equivalent somewhere. Meaning it's by definition going to be exposed to > >> superusers and replication downstreams. > > > > Another possibility is to mention the use of the new passfile > > parameter for connection strings in the docs... This removes the need > > to have plain passwords directly stored in the database. Not sure if > > that's better though because that still mean that the password is > > present in plain format somewhere. > > The real solution to "the password is present in plain form somewhere" > is probably "don't use passwords for authentication". Because, > ultimately, a password by its nature has to exist in plain form > somewhere, at least in someone's brain, and very likely in their > password manager or the post-it stuck to their desk or the Notes app > on their iPhone or similar. If the password is simple enough that the > DBA can be certain of remembering it without any sort of memory aid, > it's probably dumb simple. If the DBA has few enough distinct > passwords that he doesn't need a memory aid just on the basis of sheer > volume of passwords needing to be remembered, that's probably not good > either.
I agree that the use of plaintext passwords should be discouraged, but we don't actually provide any way to address these kinds of proxy authentication issues today except to store *some* secret somewhere on the system which, if compromised, would allow the attacker to gain access to the downstream system. There are solutions to authentication proxying and it would be great if we would implement them (Kerberos Delegation, for example, and there's a mechanism to do something similar in TLS also, iirc, and we should be able to come up with something for same-system cross-database or cross-cluster unix-socket based auth, really...), but I don't think anyone is currently working on implementing them, which is unfortunate. I tend to agree with Michael that we should make it very clear in our documentation that the password/private key/whatever has to be stored unencrypted on the filesystem somewhere today. Perhaps it doesn't need to be a big "WARNING WARNING" type of message, but it's important information which we should make sure the user is aware of. If we do implement proper proxy authentication, we will want to include documentation as to just what that means regarding attacks too (Kerberos Delegation, for example, usually means that a ticket for the remote service is stored somewhere and is valid for a period of time, meaning that a privileged attacker who has access to the system at the same time the user is using the system would be able to gain access to the remote system by stealing the delegated ticket). Thanks! Stephen
Description: Digital signature