| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dave Page <dpage(at)pgadmin(dot)org> |
| Cc: | Marko Kreen <markokr(at)gmail(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Andrew Dunstan <andrew(at)dunslane(dot)net>, mlortiz <mlortiz(at)uci(dot)cu>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Rejecting weak passwords |
| Date: | 2009-10-14 15:30:49 |
| Message-ID: | 13907.1255534249@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dave Page <dpage(at)pgadmin(dot)org> writes:
> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Kreen | 2009-10-14 15:32:08 | Re: Rejecting weak passwords |
| Previous Message | Dave Page | 2009-10-14 15:25:49 | Re: Rejecting weak passwords |