Re: scram and \password

On Wed, Mar 15, 2017 at 6:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>> On Tue, Mar 14, 2017 at 8:40 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Why exactly would anyone want "md5 only"? I should think that "scram
>>> only" is a sensible pg_hba setting, if the DBA feels that md5 is too
>>> insecure, but I do not see the point of "md5 only" in 2017. I think
>>> we should just start interpreting that as "md5 or better".
>
>> Without md5-only, a user who uses \password to change their password from a
>> newer client would lock themselves out of connecting again from older
>> clients. As a conscious decision (either of the DBA or the user) that
>> would be OK, but to have it happen by default would be unfortunate.
>
> That's a point, but what it implies is that \password needs some input
> from the user about whether to generate a SCRAM or MD5-hashed password.
> It would be a fatal error to try to drive that off the auth method
> that had been used for the current connection, even if \password had a
> way to find that out. By definition, your concern is about clients
> other than the current one, which might well be coming in from other
> addresses and getting challenges based on other pg_hba entries. So
> you can't say that "I came in on a SCRAM connection" is sufficient
> reason to generate a SCRAM password.
>
> In short, I don't think that argument refutes my position that "md5"
> in pg_hba.conf should be understood as allowing SCRAM passwords too.

I have been hacking my way through this thing, and making
scram_build_verifier is requiring a bit more refactoring than I
thought first:
- stored and server keys are hex-encoded using a backend-only routine.
I think that those should be instead base64-encoded using what has
already been moved in src/common/.
- Callers of scram_build_verifier() need to allocate by themselves the
verifier, and feed it to the function similarly to MD5.
- Frontend-side random generation function is needed, so I have moved
pg_frontend_random() into its own file in src/common/.

Attached are four patches:
- 0001: Switch server and stored keys to be base64-encoded.
- 0002: Move pg_frontend_random() to src/common/
- 0003: Move scram_build_verifier() to src/common/
- 0004: Extend PQencryptPassword with a method argument, able to
handle SCRAM, MD5 and cleartext.

I have not yet done the psql portion with \password -method (too
tired), and in 0004 all the calls of PQencryptPassword use "scram" for
the purpose of the demonstration. Even if PQencryptPassword is not
extended at the end, patches 0001~0003 are necessary anyway.
--
Michael