On Thu, Feb 13, 2025 at 8:25 PM Jacob Champion <jacob.champ...@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
