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@libpq-int.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
signature.asc
Description: PGP signature