On 12/31/23 9:50 AM, Magnus Hagander wrote:
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.
Fair point on the framework/driver comparison, but the above still applies to drivers. As mentioned above, non-libpq drivers did have mistakes that could have lead to security issues while implementing PostgreSQL SCRAM. Additionally, CVE-2021-23222[1] presented itself in both libpq/non-libpq drivers, either through the issue itself, or through implementing the protocol step in a way similar to libpq.
Keeping the implementation surface area simpler for driver maintainers does generally help mitigate further issues, though I'd defer to the driver maintainers if they agree with that statement.
Thanks, Jonathan [1] https://www.postgresql.org/support/security/CVE-2021-23222/
OpenPGP_signature.asc
Description: OpenPGP digital signature
