On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane <t...@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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
