On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane <tgl@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