| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
| Cc: | 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-13 11:17:58 |
| Message-ID: | 75619A47-4CD0-4E0F-8A30-32F83FF593DD@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 12 Dec 2022, at 15:47, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
> To throw on a bit of paint, if we do change it, we should likely follow what would come out in a RFC.
>
> While the SCRAM-SHA-512 RFC is still in draft[1], the latest draft it contains a "SHOULD" recommendation of 10000, which was bumped up from 4096 in an earlier version of the draft:
This is however the draft for a different algorithm: SCRAM-SHA-512. We are
supporting SCRAM-SHA-256 which is defined in RFC7677. The slightly lower
recommendation there makes sense as SHA-512 is more computationally expensive
than SHA-256.
It does raise an interesting point though, if we in the future add suppprt for
SCRAM-SHA-512 (which seems reasonable to do) it's not good enough to have a
single GUC for SCRAM iterations; we'd need to be able to set the iteration
count per algorithm. I'll account for that when updating the patch downthread.
--
Daniel Gustafsson https://vmware.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2022-12-13 11:35:35 | Re: Time delayed LR (WAS Re: logical replication restrictions) |
| Previous Message | PG Bug reporting form | 2022-12-13 10:57:39 | BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) |