Re: Password leakage avoidance

On 12/24/23 12:15 PM, Tom Lane wrote:

>> Maybe we need a PQcreaterole that provide the mechanism to set passwords
>> safely. It'd likely need to take all the options need for creating a
>> role, but that would at least give the underlying mechanism to ensure
>> we're always sending a hashed password to the server.
>
> I'm kind of down on that, because it seems like it'd be quite hard to
> design an easy-to-use C API that doesn't break the next time somebody
> adds another option to CREATE USER. What's so wrong with suggesting
> that the password be set in a separate step? (For comparison, typical
> Unix utilities like useradd(8) also tell you to set the password
> separately.)

Modern development frameworks tend to reduce things down to one-step,
even fairly complex operations. Additionally, a lot of these frameworks
don't even require a developer to build backend applications that
involve doing actually work on the backend (e.g. UNIX), so the approach
of useradd(8) et al. are not familiar. Adding the additional step would
lead to errors, e.g. the developer not calling the "change password"
function to create the obfuscated password. Granted, we can push the
problem down to driver authors to "be better" and simplify the process
for their end users, but that still can be error prone, having seen this
with driver authors implementing PostgreSQL SCRAM and having made
(correctable) mistakes that could have lead to security issues.

That said, I see why trying to keep track of all of the "CREATE ROLE"
attributes from a C API can be cumbersome, so perhaps we could end up
adding an API that just does "create-user-with-password" and applies a
similar method to Joe's patch. That would also align with the developer
experience above, as in those cases users tend to just be created with a
password w/o any of the additional role options.

Also open to punting this to a different thread as we can at least make
things better with the "change password" approach.

Thanks,

Jonathan