| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Enhancements to passwordcheck |
| Date: | 2017-09-27 14:43:30 |
| Message-ID: | F3F63E2E-91A1-4DA4-BC29-584054D8DA1D@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/27/17, 7:41 AM, "Peter Eisentraut" <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 9/25/17 23:10, Bossart, Nathan wrote:
>> One interesting design challenge will be how to handle pre-hashed
>> passwords, since the number of checks we can do on those is pretty
>> limited. I'm currently thinking of a parameter that can be used to
>> block, allow, or force pre-hashed passwords.
>
> Pre-hashed passwords are the normal case. You can't break that without
> making this module a net loss in security.
A strength in making this configurable is that you could use it to
enforce that passwords are pre-hashed. But yes, blocking pre-
hashed passwords could be undesirable given an untrusted network or
server.
Nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2017-09-27 15:06:49 | Re: Enhancements to passwordcheck |
| Previous Message | Tom Lane | 2017-09-27 14:39:59 | Re: [HACKERS] Float value 'Infinity' is cast to numeric 1 on Windows |