Re: SCRAM pass-through authentication for postgres_fdw

Thanks for the comments!

On 04/12/24 19:11, Jacob Champion 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?
Yes, from the tests that I've performed I would say that this is the
only requirement.

> 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 think that both can be use cases. In case of using with different
servers it can be another option over the plain-text password approach.

I'm attaching a v2 patch with a TAP test that validate the both use
cases. For connections with different servers an ALTER ROLE <role>
PASSWORD <encrypted_password> is required, so that both servers have
identical verifiers.

>> - pg_hmac_ctx *ctx = pg_hmac_create(state->hash_type);
>> + pg_hmac_ctx *ctx = pg_hmac_create(PG_SHA256);
>
> Why was that change made?

Not needed, sorry. Fixed on v2

--
Matheus Alcantara
EDB: https://www.enterprisedb.com