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