On 5/23/23 21:37, Michael Paquier wrote:
> On Tue, May 23, 2023 at 10:01:03PM -0400, Stephen Frost wrote:
>> To the extent that there was an issue when it was implemented ... it's
>> now been implemented and so that was presumably overcome (though I don't
>> really specifically recall what the issues were there? Seems like it
>> wouldn't matter at this point though), so I don't understand why we
>> would wish to revisit it.
>
> Well, there are IMO two sides issues here:
> 1) libpq sends an empty username, which can be an issue if attempting
> to make this layer more pluggable with other things that are more
> compilation than PG with the SCRAM exchange (OpenLDAP is one, there
> could be others).
> 2) The backend ignoring the username means that it is not mixed in the
> hashes.
+1
> Relying on channel binding mitigates the range of problems for 2),
(Except for username tampering with possession of the server key alone.
As spec'd, that shouldn't be possible. But for the vast majority of
users, I think that's probably not on the list of plausible concerns.)
> now
> one thing is that the default sslmode does not enforce an SSL
> connection, either, though this default has been discussed a lot. So
> I am really wondering whether there wouldn't be some room for a more
> compliant, strict HBA option with scram-sha-256 where we'd only allow
> UTF-8 compliant strings. Just some food for thoughts.
>
> And we could do better about the current state that's 1), anyway.
I would definitely like to see improvements in this area. I don't think
we'd need to break compatibility with clients, either (unless the server
operator explicitly wanted to). The hard part is mainly on the server
side, when dealing with a mismatch between the startup packet and the
SCRAM header.
--Jacob