On Wed, Oct 14, 2009 at 18:25, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dave Page <dp...@pgadmin.org> writes: >> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I see one, and I proposed masking passwords in any relevant queries >> before they were written to the stats or logs to mitigate that. > > Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to > throw a syntax error before you realize there's anything there that > might need to be protected).
I'm unsure if it's our responsibility to think about that. We can leak a *lot* of sensitive information to the logs through syntax errors, this is just one of them. We *do* need to worry about the statements when they are sent properly, of course. So throwing out a wild idea that's probably just wild enough to even consider, but one way to deal with the logging side of things would be to deprecate/remove ALTER USER/CREATE USER with password, and add a separate API call. With a separate wire protocol packet. That would certainly take care of the logging part ;) > And you ignored the question of insecure transmission pathways, anyway. > By the time the backend has figured out that it's got a CREATE USER > ... PASSWORD command, it's already way too late if the client sent it > over a non-SSL connection. Encryption policy of this type cannot be set at the server. Ever. And it shouldn't. If the sysadmin is worried someone might sniff the traffic, he should require SSL, or use a VPN, or similar things. If he's fine with letting the client decide, then it's not a problem, because it's up to the client not to send the password that way. And if the client did, well, the sysadmin just said it was ok to let the client decide, so we're ok. > Marko has pointed out repeatedly that a plugin can catch the worst > cases of insecure passwords even when given a pre-md5'd password. > So you can use a plugin that does it that way, or if you want you > can use a plugin that throws error on a pre-md5'd password. I do > not see a reason for us to add a boatload of questionable logic > that favors the latter approach. it lets you find some passwords, but it does not let you set a *policy*. As is often required by security policies etc. Does anybody know how other databases that *do* implement this solve the problem? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
