On Mon, Oct 31, 2022 at 1:27 PM Jonathan S. Katz <jk...@postgresql.org> wrote: > Having a set of SCRAM secret building functions would help in a few areas:
I have mixed-to-negative feelings about this. Orthogonality with other methods seems reasonable, except we don't really recommend that people use those other methods today. SCRAM is supposed to be one of the solutions where the server does not know your password at any point and cannot impersonate you to others. If we don't provide an easy client-side equivalent for the new functionality, via \password or some such, then the path of least resistance for some of these intermediate use cases (i.e. higher iteration count) will be "just get used to sending your password in plaintext," and that doesn't really sound all that great. Similar to pgcrypto's current state. > 2. Keeping a history file of user-stored passwords Could you expand on this? How does being able to generate SCRAM secrets help you keep a password history? > or checking against a common-password dictionary. People really want to do this using SQL? Maybe my idea of the use case is way off, but I'm skeptical that this scales (safely and/or performantly) to a production system, *especially* if you have your iteration counts high enough. > 3. Allowing users to build SQL-functions that can precompute SCRAM > secrets on a local server before sending it to a remote server. I guess I have fewer problems with this use case in theory, but I'm wondering if better client-side support might also solve this one as well, without the additional complication. Is there a reason it would not? Thanks, --Jacob
