Re: Password leakage avoidance

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