Re: Rejecting weak passwords

On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>> IOW, having plaintext password in CREATE/ALTER time which can
>> then checked for weaknesses is better that MD5 password, which
>> actually does not increase security.
>
> This is not acceptable and will not happen.  The case that ENCRYPTED
> protects against is database superusers finding out other users'
> original passwords, which is a security issue to the extent that those
> users have used the same/similar passwords for other systems.
> We're not going to give up protection for that in order to provide
> an option to do weak-password checking in a place that simply isn't
> the best place to do it anyway.

This is an area in which we often get beaten up in in technical
evaluations against other DBMSs. Password complexity checks are pretty
much standard features in other products and it hurts our adoption not
to be able to offer them, especially in large shops where the first
phase of the eval may be a simple box-checking exercise.

I would suggest that in addition to the proposed plugin, we add an
suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED
PASSWORD to ensure that the password complexity can be checked when
roles are created or modified.

In the default case, the current behaviour would not change.

With the GUC turned on, passwords could be forced through the
validation module. To allow dumps to remain secure, the GUC can be
turned off by the DBA prior to loading, or in the dump itself. Logging
of CREATE/ALTER users statements in this mode could be special-cased
to prevent passwords going to the logs/stats (not sure what overhead
that might incur though). In addition, the docs for the GUC would
obviously point out that it should only be used in conjunction with
SSL connections.

This would allow us to remain secure-by-default, and yet offer an
important option for many potential users.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com