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