| From: | Jacob Champion <jchampion(at)timescale(dot)com> |
|---|---|
| To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: Docs: Encourage strong server verification with SCRAM |
| Date: | 2023-05-26 22:47:18 |
| Message-ID: | CAAWbhmgu5g6ybdqmtDdS-WjLNO2aniqYQqcRXzmiVSKJJj-x_w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 25, 2023 at 6:10 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
> I read through the proposal and like this much better.
Great!
> I rewrote this to just focus on server spoofing that can occur with
> SCRAM authentication and did some wordsmithing. I was torn on keeping in
> the part of offline analysis of an intercepted hash, given one can do
> this with md5 as well, but perhaps it helps elaborate on the consequences.
This part:
> + To prevent server spoofing from occurring when using
> + <link linkend="auth-password">scram-sha-256</link> password authentication
> + over a network, you should ensure you are connecting using SSL.
seems to backtrack on the recommendation -- you have to use
sslmode=verify-full, not just SSL, to avoid handing a weak(er) hash to
an untrusted party.
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-05-26 23:05:01 | Re: Cleaning up nbtree after logical decoding on standby work |
| Previous Message | Peter Geoghegan | 2023-05-26 22:19:55 | Re: Cleaning up nbtree after logical decoding on standby work |