On Wed, Dec 4, 2024 at 10:45 AM 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 = pg_hmac_create(state->hash_type);
> + pg_hmac_ctx *ctx = pg_hmac_create(PG_SHA256);
Why was that change made?
Thanks,
--Jacob
[1] https://datatracker.ietf.org/doc/html/rfc5802#section-9
