Re: Rejecting weak passwords

On 10/14/09, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane <tgl@sss.pgh.pa.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.

Checking 1M common weak combinations against the md5 hashed password
will take < 1s.  You cannot count the commas in password, but thats it.
The usual problems: 'username', '1234' can be still detected.

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

-- 
marko