On 1/2/24 7:23 AM, Sehrope Sarkuni wrote:
Having worked on and just about wrapped up the JDBC driver patch for this, couple thoughts:
2. Password encoding should be split out and made available as its own functions. Not just as part of a wider "create _or_ alter a user's password" function attached to a connection. We went a step further and added an intermediate function that generates the "ALTER USER ... PASSWORD" SQL.
I agree with this. It's been a minute, but I had done some refactoring on the backend-side to support the "don't need a connection" case for SCRAM secret generation functions on the server-side[1]. But I think in general we should split out the password generation functions, which leads to:
5. Our SCRAM specific function allows for customizing the algo iteration and salt parameters. That topic came up on hackers previously[1]. Our high level "alterUserPassword(...)" function does not have those options but it is available as part of our PasswordUtil SCRAM API for advanced users who want to leverage it. The higher level functions have defaults for iteration counts (4096) and salt size (16-bytes).
This seems like a good approach -- the regular function just has the defaults (which can be aligned to the PostgreSQL defaults) (or inherit from the server configuration, which then requires the connection to be present) and then have a more advanced API available.
Thanks, Jonathan[1] https://www.postgresql.org/message-id/3a9b7126-01a0-7e1a-1b2a-a76df6176725%40postgresql.org
OpenPGP_signature.asc
Description: OpenPGP digital signature
