| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Rejecting weak passwords |
| Date: | 2009-09-28 14:46:07 |
| Message-ID: | 545.1254149167@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Albe Laurenz wrote:
>> 1) One could have a set of GUCs like min_password_length,
>> min_password_nonchars and similar that everybody
>> could configure. This is not extremely flexible though.
>> 2) Another idea would be a GUC that contains a regular
>> expression that a password may *not* match.
>> Perhaps that's too limiting too.
>> 3) I have also considered a GUC that points to a loadable
>> module that performs the password check if set.
> My vote is for #3, if anything.
Yeah. I think there is no chance of anything in this vein getting
accepted into core Postgres, if only because everybody will have a
different idea of what it needs to do. A hook function (no need
for a GUC) would be a reasonable proposal.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2009-09-28 15:05:39 | Re: WIP - syslogger infrastructure changes |
| Previous Message | Tom Lane | 2009-09-28 14:43:28 | Re: syslog_line_prefix |