From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Raising the SCRAM iteration count |
Date: | 2022-12-15 00:00:54 |
Message-ID: | a20abcf0-5e8b-0e99-4953-f5718409e957@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/14/22 6:52 PM, Michael Paquier wrote:
> On Wed, Dec 14, 2022 at 01:59:04PM -0500, Jonathan S. Katz wrote:
HA-256 that we will just need to pick up?
>
>>> The attached v2 has the GUC rename and a change to GUC_REPORT such that the
>>> frontend can use the real value rather than the default. I kept it for super
>>> users so far, do you think it should be a user setting being somewhat sensitive?
>>
>> No, because a user can set the number of iterations today if they build
>> their own SCRAM secret. I think it's OK if they change it in a session.
>>
>> If a superuser wants to enforce a minimum iteration count, they can write a
>> password_check_hook. (Or we could add another GUC to enforce that).
>
> Hm? check_password_hook does not allow one to recompile the password
> given by the user, except if I am missing your point?
My point is you can write a hook to reject the password if the iteration
count is "too low". Not to re-hash the password.
Thanks,
Jonathan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-12-15 00:12:26 | Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX |
Previous Message | Michael Paquier | 2022-12-14 23:52:32 | Re: Raising the SCRAM iteration count |