On Wed, Dec 27, 2023 at 10:31 PM Jonathan S. Katz <jk...@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/
