Re: Rejecting weak passwords

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