Re: Password leakage avoidance

On 12/31/23 9:50 AM, Magnus Hagander wrote:
> 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.

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/