| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: User functions for building SCRAM secrets |
| Date: | 2022-11-30 01:12:00 |
| Message-ID: | Y4at4BnxtPPH6w5g@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 29, 2022 at 09:32:34PM +0100, Daniel Gustafsson wrote:
> On the whole I tend to agree with Jacob upthread, while this does provide
> consistency it doesn't seem to move the needle for best practices. Allowing
> scram_build_secret_sha256('password', 'a', 1); with the password potentially
> going in cleartext over the wire and into the logs doesn't seem like a great
> tradeoff for the (IMHO) niche usecases it would satisfy.
Should we try to make \password and libpq more flexible instead? Two
things got discussed in this area since v10:
- The length of the random salt.
- The iteration number.
Or we could bump up the defaults, and come back to that in a few
years, again.. ;p
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2022-11-30 01:12:47 | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
| Previous Message | Michael Paquier | 2022-11-30 01:00:55 | Re: Collation version tracking for macOS |