On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dave Page <dp...@pgadmin.org> writes: >> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
