On Thu, Feb 13, 2025 at 8:25 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> > I also agree that we should enforce the use of the SCRAM on the remote for
> > safety. To do this I think that we could set require_auth=scram-sha-256 on
> > connection options if SCRAM pass-through is being used, with this we will get a
> > connection error. WYT?
>
> We would need to verify that the user mapping can't overwrite that
> with its own (less trusted) `require_auth` setting. (I think that
> should be true already, but I'm not 100% sure.)
>
Yeah, this is true. The user mapping and the fdw options can overwrite this.
I'll work on a fix for this.
> Hardcoding to scram-sha-256 would also prohibit the use of GSS or
> standard password auth, now that I think about it. The docs currently
> have a note about being able to choose... Should we add the other
> permitted authentication types, i.e. `password,md5,scram-sha-256,gss`?
> Or should we prohibit the use of other auth types if you've set
> use_scram_passthrough? Or maybe there's an easier way to enforce the
> use of the SCRAM keys, that better matches the current logic in
> dblink_security_check?
>
But would it be possible to use SCRAM pass-through feature using another auth
method? We need the scram keys (that is saved on MyProcPort during
scram_exchange) to perform the pass-through which I think that we would not
have with another auth type? That being said I think that we could prohibit the
usage of other auth types when use_scram_passthrough is set, what do you think?
--
Matheus Alcantara
