Re: Docs: Encourage strong server verification with SCRAM

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Jacob Champion <jchampion(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Subject: Re: Docs: Encourage strong server verification with SCRAM
Date: 2023-05-24 04:37:15
Message-ID: ZG2Ue6dhumThsxJE@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Relying on channel binding mitigates the range of problems for 2), 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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2023-05-24 05:23:02 Re: PG 16 draft release notes ready
Previous Message Bruce Momjian 2023-05-24 04:34:06 Instructions for creating the Postgres major release notes