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
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 |