On Thu, May 25, 2023 at 10:48 AM Jonathan S. Katz <jk...@postgresql.org> wrote:
> Overall, +1 to tightening the language around the docs in this area.
>
> However, to paraphrase Stephen, I think the language, as currently
> written, makes the problem sound scarier than it actually is, and I
> agree that we should just inline it above.
How does v2 look? I more or less divided the current text into a local
section and a network section. (I'm still not clear on where in the
current text you're wanting me to inline a sudden aside on SCRAM; it
doesn't really seem to fit in any of the existing paragraphs.)
--Jacob
From 96dee3dead97d38afd0d8139f5c9954ab76dfcba Mon Sep 17 00:00:00 2001
From: Jacob Champion <jchamp...@timescale.com>
Date: Mon, 22 May 2023 16:46:23 -0700
Subject: [PATCH v2] docs: encourage strong server verification with SCRAM
The server verification in libpq's SCRAM implementation can be subverted
in various ways. While mitigations for some of the issues exist, it's
probably wise for most users to combine it with strong server
authentication, to avoid entering a SCRAM exchange with an untrusted
server. Recommend that in the docs.
---
doc/src/sgml/runtime.sgml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index dbe23db54f..35993ffff2 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1994,6 +1994,20 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
the socket.
</para>
+ <para>
+ An additional avenue for server spoofing is via the network. Active attackers
+ who successfully insert themselves between the client and the real server can
+ not only read data coming from the client, as above, but also read data
+ coming from the server or tamper with data sent by either peer. The strongest
+ form of password authentication
+ (<link linkend="auth-password">scram-sha-256</link> in combination with
+ <literal>channel_binding=require</literal>) can provide partial mitigation,
+ but the current SCRAM implementation in libpq cannot protect the entire
+ authentication exchange, and an active attacker can retrieve a hashed
+ password from the client for offline analysis, even if they cannot complete
+ the exchange successfully.
+ </para>
+
<para>
To prevent spoofing on TCP connections, either use
SSL certificates and make sure that clients check the server's certificate,
--
2.25.1
