On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> 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.
>
> That's going to stop us from being beat up? A GUC that forcibly
> *weakens* security? I can't see it.
If the communications channel uses SSL, and passwords are prevented
from hitting the logs then (assuming there are no other weaknesses I
haven't thought of), then the net effect would surely be tighter
overall security?
In a very security-conscious shop, the DBA won't have access to the
underlying system at all, so debugging tools etc would be out of the
question. In most shops, he will have access and can already just set
the auth method to 'password' and then break out the debugger (or even
replace the executables), so I can't see that this option would open
up any obvious new attack vectors.
Users are almost always the biggest weak-point in any security system,
so should naturally be the first hole we look at plugging, before the
ones that are much harder to exploit effectively - especially when
those are only open to exploit by people who already have superuser
privileges!
> If you're really intent on making that happen, you can have your
> password checker plugin reject crypted passwords; we don't need
> such a questionable rule in core.
Client software would need to have a standard way to know when to use
ENCRYPTED PASSWORD or not.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com