On Wed, Dec 27, 2023 at 10:31 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> 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.
This seems to confuse "driver" with "framework".
I would say the "two step" approach is perfectly valid for a driver
whereas as you say most people building say webapps or similar on top
of a framework will expect it to handle things for them. But that's
more of a framework thing than a driver thing, depending on
terminology. E.g. it would be up to the "Postgres support driver" in
django/rails/whatnot to reduce it down to one step, not to a low level
driver like libpq (or other low level drivers).
None of those frameworks are likely to want to require direct driver
access anyway, they *want* to take control of that process in my
experience.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/