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
OpenPGP_signature.asc
Description: OpenPGP digital signature
