On Wed, Dec 4, 2024 at 10:45 AM Matheus Alcantara <matheusssil...@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
