On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
>
> Oh, so you want us to propagate extra support for this blatant security
> reduction all over the system too? No thank you.
You've twice asserted it's a reduction without providing any arguments
to back that up. I argue that you *possibly* open a very hard to
exploit hole, which is exploitable only by sysadmins/DBAs, in return
for which you close a very large hole that allows users to reuse
passwords or use common or easy to guess words.
If I am incorrect or have missed an important point, please explain why or what.
> This whole line of discussion just proves the point that was made
> originally: it would be a lot better to do whatever checking you want
> done on the client side, rather than risk transmitting unencrypted
> passwords. If you are going to imagine that client-side software knows
> about such a GUC, you might as well imagine that they have cracklib
> built in.
Surely you can see that it is *absolutely pointless* to put an
password complexity checking in the client? All a user would need to
do is grab a copy of psql to bypass it. If they can't do that, there's
probably a scripting language or 12 that would make it similarly easy.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
