From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SCRAM pass-through authentication for postgres_fdw |
Date: | 2024-12-04 23:05:00 |
Message-ID: | CAGECzQQeq5ze1XBwhb+hbqoOicv5W95GanHA6=x1YG_mnbZyww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 4 Dec 2024 at 23:11, Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> 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 don't think that necessarily has to be the usecase,
clustering/sharding setups could benefit from this too. PgBouncer
supports the same functionality[1]. I only see advantages over the
alternative, which is copying the plaintext password around. In case
of compromise of the server, only the salt+verifier has to be rotated,
not the actual user password.
Regarding the actual patch: This definitely needs a bunch of
documentation explaining how to use this and when not to use this.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-12-04 23:16:31 | Re: Cannot find a working 64-bit integer type on Illumos |
Previous Message | Jelte Fennema-Nio | 2024-12-04 22:53:52 | Re: Proposal: Role Sandboxing for Secure Impersonation |