From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
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-11 03:32:38 |
Message-ID: | Y5VPVlwE/a+CzZCZ@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Dec 11, 2022 at 12:46:23AM +0100, Daniel Gustafsson wrote:
> SCRAM with an iteration count of 1 still provides a lot of benefits over md5,
> so if we can make those comparable in performance then that could be a way
> forward (with the tradeoffs properly documented).
Okay, it looks like there is a wish to make that configurable anyway,
and I have a few comments about that.
{"scram_iteration_count", PGC_SUSET, CONN_AUTH_AUTH,
+ gettext_noop("Sets the iteration count for SCRAM secret generation."),
+ NULL,
+ GUC_NOT_IN_SAMPLE | GUC_SUPERUSER_ONLY
+ },
Shouldn't this be user-settable as a PGC_USERSET rather than
PGC_SUSET which would limit its updates to superusers?
As shaped, the GUC would not benefit to \password, and we should not
encourage users to give a raw password over the wire if possible if
they wish to compute a verifier with a given interation number.
Hence, wouldn't it be better to mark it as GUC_REPORT, and store its
status in pg_conn(at)libpq-int(dot)h in the same fashion as
default_transaction_read_only and hot_standby? This way,
PQencryptPasswordConn() would be able to feed on it automatically
rather than always assume the default implied by
pg_fe_scram_build_secret().
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Anton A. Melnikov | 2022-12-11 03:50:49 | Re: [BUG] Logical replica crash if there was an error in a function. |
Previous Message | Peter Geoghegan | 2022-12-11 02:11:21 | Re: New strategies for freezing, advancing relfrozenxid early |