Re: Refactor SCRAM code to dynamically handle hash type and key length

On Tue, Dec 20, 2022 at 08:45:29PM -0500, Jonathan S. Katz wrote:
> On 12/20/22 2:25 AM, Michael Paquier wrote:
>> 4) The case of MD5 is something that looks a bit tricky at quick
>> glance. We know that if the role has a MD5 password stored, we will
>> fail anyway. So we could just advertise the SHA-256 mechanisms in
>> this case and map the mock to that?
>
> Is this the case where we specify "md5" as the auth method but the
> user-password is stored in SCRAM?

Yes. A port storing uaMD5 with a SCRAM password makes the backend use
SASL for the whole exchange. At quick glance, we could fallback to
look at the password of the user sent by the startup packet and
advertise the mechanisms based on that because we know that one user
=> one password currently. I'd need to double-check on the RFCs to
see if there is anything specific here to worry about. The recent
ones being worked on may tell more.

>> 5) The mechanism choice in libpq needs to be reworked a bit based on
>> what the backend sends. There may be no point in advertising all the
>> SHA-256 and SHA-512 mechanisms at the same time, I guess.
>
> Yeah, I think a user may want to select which ones they want to use (e.g.
> they may not want to advertise SHA-256).

Yep, they should be able to do so. libpq should select the strongest
one if the server sends all of them, but things like
https://commitfest.postgresql.org/41/3716/ should be able to enforce
one over the other.
--
Michael