MIME-Version: 1.0
References: <27b29a35-9b96-46a9-bc1a-914140869dac@gmail.com>
In-Reply-To: <27b29a35-9b96-46a9-bc1a-914140869dac@gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Wed, 4 Dec 2024 14:11:31 -0800
Message-ID: <CAOYmi+=tX4a_eXU5bhj+z7w0ZkZ-EAQ9YLYSnoGxjmdFw8AHxA@mail.gmail.com>
Subject: Re: SCRAM pass-through authentication for postgres_fdw
To: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2B%3DtX4a_eXU5bhj%2Bz7w0ZkZ-EAQ9YLYSnoGxjmdFw8AHxA%40mail.gmail.com>
Precedence: bulk

On Wed, Dec 4, 2024 at 10:45=E2=80=AFAM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> This is achieved by storing the SCRAM ClientKey and ServerKey obtained
> during client authentication with the backend. These keys are then
> used to complete the SCRAM exchange between the backend and the fdw
> server, eliminating the need to derive them from a stored plain-text
> password.

What are the assumptions that have to be made for pass-through SCRAM
to succeed? Is it just "the two servers have identical verifiers for
the user," or are there others?

It looks like the patch is using the following property [1]:

   If an attacker obtains the authentication information from the
   authentication repository and either eavesdrops on one authentication
   exchange or impersonates a server, the attacker gains the ability to
   impersonate that user to all servers providing SCRAM access using the
   same hash function, password, iteration count, and salt.  For this
   reason, it is important to use randomly generated salt values.

It makes me a little uneasy to give users a reason to copy identical
salts/verifiers around... But for e.g. a loopback connection, it seems
like there'd be no additional risk. Is that the target use case?

I haven't looked at the code very closely yet, but the following hunk
jumped out at me:

> -    pg_hmac_ctx *ctx =3D pg_hmac_create(state->hash_type);
> +    pg_hmac_ctx *ctx =3D pg_hmac_create(PG_SHA256);

Why was that change made?

Thanks,
--Jacob

[1] https://datatracker.ietf.org/doc/html/rfc5802#section-9