On Wed, Oct 14, 2009 at 5:25 PM, 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). > > 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.
These are exactly the sort of issues I've been trying to get you to comment on. Thank you. > Marko has pointed out repeatedly that a plugin can catch the worst > cases of insecure passwords even when given a pre-md5'd password. My issues with that approach is that you may have to maintain a huge library of passwords - which you're never going to do efficiently or effectively if you assume that users may use simple variations of their username for example - eg. t0mlane. > 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. My only concern with that idea is having some way for the client to know when to not hash the password. Figuring that out from a specific error code and then retrying would be inefficient, ugly, and in the case of pgAdmin, quite hard to do given the way that SQL is generated and then executed. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
