On Tue, Feb 28, 2023 at 6:53 PM Stephen Frost wrote:
> * Jacob Champion (jchamp...@timescale.com) wrote:
> > Yes. Interoperable authentication is going to have to solve those
> > sorts of problems somehow, though. And there are a bunch of levers to
> > pull: clients aren't required to run their
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On Mon, Feb 27, 2023 at 12:43 PM Stephen Frost wrote:
> > * Jacob Champion (jchamp...@timescale.com) wrote:
> > > This patchset should ideally have required zero client side changes, but
> > > because our SCRAM implementation is
On Mon, Feb 27, 2023 at 12:43 PM Stephen Frost wrote:
> * Jacob Champion (jchamp...@timescale.com) wrote:
> > This patchset should ideally have required zero client side changes, but
> > because our SCRAM implementation is slightly nonstandard too -- it
> > doesn't embed the username into the
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> This patchset should ideally have required zero client side changes, but
> because our SCRAM implementation is slightly nonstandard too -- it
> doesn't embed the username into the SCRAM data -- libpq can't talk to
> the OpenLDAP/Cyrus
(Splitting off a new thread, and mostly clearing the CC list so people
can escape if they want, because this is a heckuva tangent.)
TL;DR: the attached patchset lets you authenticate with Postgres by
forwarding SCRAM authentication to a backend LDAP server, and I use it
to make arguments for
Greetings,
* Andrey Chudnovsky (achudnovs...@gmail.com) wrote:
> The thread link is here:
> https://www.postgresql.org/message-id/flat/CABkiuWo4fJQ7dhqgYLtJh41kpCkT6iXOO8Eym3Rdh5tx2RJCJw%40mail.gmail.com#f94c36969a68a07c087fa9af0f5401e1
Thanks for pointing out the updates on that thread, I've
Greetings,
Want to resurface the OAUTH support topic in the context of the
concerns raised here.
> How about- if we just added OAUTH support directly into libpq and the
> backend, would that work with Azure's OIDC provider? If not, why not?
> If it does, then what's the justification for trying
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-08-03 17:21:58 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2022-08-03 16:28:08 -0400, Stephen Frost wrote:
> > > > Again, server-side only is not interesting and not a direction that
> > > >
Hi,
On 2022-08-03 17:21:58 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2022-08-03 16:28:08 -0400, Stephen Frost wrote:
> > > Again, server-side only is not interesting and not a direction that
> > > makes sense to go in because it doesn't provide any way to
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-08-03 16:28:08 -0400, Stephen Frost wrote:
> > Again, server-side only is not interesting and not a direction that
> > makes sense to go in because it doesn't provide any way to have
> > trust established in both directions, which
Hi,
On 2022-08-03 16:28:08 -0400, Stephen Frost wrote:
> Again, server-side only is not interesting and not a direction that
> makes sense to go in because it doesn't provide any way to have
> trust established in both directions, which is what all modern
> authentication methods do
Greetings,
* samay sharma (smilingsa...@gmail.com) wrote:
> On Tue, Aug 2, 2022 at 2:48 PM Jacob Champion
> wrote:
> > [dev hat] That said, I plan to do some additional dev work on top of
> > this over the next couple of months. The ideal case would be to provide
> > a server-only extension that
Hi Jacob,
On Tue, Aug 2, 2022 at 2:48 PM Jacob Champion
wrote:
> [CFM hat] Okay, either way you look at it, this patchset needs author
> work before any further review can be done. Peter has given some
> additional feedback on next steps, Stephen has asked for clarification
> on the goals of
[CFM hat] Okay, either way you look at it, this patchset needs author
work before any further review can be done. Peter has given some
additional feedback on next steps, Stephen has asked for clarification
on the goals of the patchset, etc. I feel pretty confident in marking
this Returned with
s://www.postgresql.org/message-id/20220318032520.t2bcwrnterg6lq6g%40alap3.anarazel.de
> > > when describing the above, that's not enough to implement every desireable
> > > authentication method - but there's real use-cases where using the
> > > existing
> > > SAS
On 15.03.22 20:27, samay sharma wrote:
This patch-set adds the following:
* Allow multiple custom auth providers to be registered (Addressing
feedback from Aleksander and Andrew)
* Modify the test extension to use SCRAM to exchange secrets (Based on
Andres's suggestion)
* Add support for
n
> > https://www.postgresql.org/message-id/20220318032520.t2bcwrnterg6lq6g%40alap3.anarazel.de
> > when describing the above, that's not enough to implement every desireable
> > authentication method - but there's real use-cases where using the existing
> > SASL-SCRAM-256
ion method - but there's real use-cases where using the existing
> SASL-SCRAM-256 is sufficient.
That this apparently isn't actually about adding new authentication
protocols or methods sure strikes me as odd when folks were adjusting
proposed patches specificially to use this for new au
Hi,
On 2022-03-18 00:45:49 -0400, Stephen Frost wrote:
> > I also don’t think that I agree that it’s acceptable to only have the
> > > ability to extend the authentication on the server side as that implies a
> > > whole bunch of client-side work that goes above and beyond just
> > > implementing
Greetings,
On Fri, Mar 18, 2022 at 00:24 Andres Freund wrote:
> Hi,
>
> On 2022-03-18 00:03:37 -0400, Stephen Frost wrote:
> > On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> > > It's imo a separate project to make the client side extensible. There's
> > > plenty
> > > of authentication
Hi,
On 2022-03-18 00:03:37 -0400, Stephen Frost wrote:
> On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> > It's imo a separate project to make the client side extensible. There's
> > plenty
> > of authentication methods that don't need any further client side support
> > than
> > the
Greetings,
On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> On 2022-03-17 22:13:27 -0400, Stephen Frost wrote:
> > This isn’t the first time I asked about this on this thread, yet the
> > question about why this is only being discussed as backend changes, and
> > with the only goal seeming
Hi,
On 2022-03-17 22:13:27 -0400, Stephen Frost wrote:
> This isn’t the first time I asked about this on this thread, yet the
> question about why this is only being discussed as backend changes, and
> with the only goal seeming to be to have a backend loadable module, without
> anything on the
Greetings,
On Thu, Mar 17, 2022 at 17:02 Andres Freund wrote:
> On 2022-03-16 18:50:23 -0400, Stephen Frost wrote:
> > First, let's be clear- we aren't actually talking about custom or
> > pluggable authentication here, at least when it comes to PG as a
> > project. For it to actually be
On 2022-03-16 18:50:23 -0400, Stephen Frost wrote:
> First, let's be clear- we aren't actually talking about custom or
> pluggable authentication here, at least when it comes to PG as a
> project. For it to actually be pluggable, it needs to be supported on
> both the client side and the server
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-17 14:03:31 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > > > Looking at the existing authentication methods
> > > >
> > > > # METHOD
On Thu, 2022-03-17 at 14:03 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> >
> > trust, reject, md5, password, ident, peer, pam, ldap, radius look trivially
> > possible. I think sspi is doable as well, but I don't know it well enough to
> > be confident. gss without
Hi,
On 2022-03-17 14:03:31 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > > Looking at the existing authentication methods
> > >
> > > # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
>
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > Looking at the existing authentication methods
> >
> > # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
> > # "gss", "sspi", "ident", "peer", "pam", "ldap",
Hi,
On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> Looking at the existing authentication methods
>
> # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
> # "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert".
>
> how many of these could have been
On 16.03.22 21:27, samay sharma wrote:
The only goal of this patch wasn't to enable support for Azure AD.
That's just one client. Users might have a need to add or change auth
methods in the future and providing that extensibility so we don't need
to have core changes for each one of them
Greetings,
* samay sharma (smilingsa...@gmail.com) wrote:
> On Wed, Mar 16, 2022 at 8:02 AM Stephen Frost wrote:
> > How about- if we just added OAUTH support directly into libpq and the
> > backend, would that work with Azure's OIDC provider? If not, why not?
>
> Overall, Azure AD implements
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Wed, 2022-03-16 at 11:02 -0400, Stephen Frost wrote:
> > That we're having to extend this quite a bit to work for the proposed
> > OAUTH patches and that it still doesn't do anything for the client
> > side
> > (note that the OAUTHBEARER
On Tue, 2022-03-15 at 12:27 -0700, samay sharma wrote:
> This patch-set adds the following:
>
> * Allow multiple custom auth providers to be registered (Addressing
> feedback from Aleksander and Andrew)
> * Modify the test extension to use SCRAM to exchange secrets (Based
> on Andres's
Hi,
On Wed, Mar 16, 2022 at 8:02 AM Stephen Frost wrote:
> Greetings,
>
> * samay sharma (smilingsa...@gmail.com) wrote:
> > On Fri, Mar 4, 2022 at 11:15 AM Jacob Champion
> wrote:
> > > On Thu, 2022-03-03 at 11:12 +0100, Peter Eisentraut wrote:
> > > > At the moment, it is not possible to
On Wed, 2022-03-16 at 11:02 -0400, Stephen Frost wrote:
> That we're having to extend this quite a bit to work for the proposed
> OAUTH patches and that it still doesn't do anything for the client
> side
> (note that the OAUTHBEARER patches are still patching libpq to add
> support directly and
Greetings,
* samay sharma (smilingsa...@gmail.com) wrote:
> On Fri, Mar 4, 2022 at 11:15 AM Jacob Champion wrote:
> > On Thu, 2022-03-03 at 11:12 +0100, Peter Eisentraut wrote:
> > > At the moment, it is not possible to judge whether the hook interface
> > > you have chosen is appropriate.
> > >
Hi,
On Fri, Mar 4, 2022 at 11:15 AM Jacob Champion wrote:
> On Thu, 2022-03-03 at 11:12 +0100, Peter Eisentraut wrote:
> > At the moment, it is not possible to judge whether the hook interface
> > you have chosen is appropriate.
> >
> > I suggest you actually implement the Azure provider, then
On Tue, Mar 8, 2022 at 9:28 PM Stephen Frost wrote:
>
> Greetings,
>
> * Jeff Davis (pg...@j-davis.com) wrote:
> > On Wed, 2022-03-02 at 10:54 -0500, Stephen Frost wrote:
> > > It's our decision what we want to support and maintain in the code
> > > base
> > > and what we don't.
> >
> > That
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Wed, 2022-03-02 at 10:54 -0500, Stephen Frost wrote:
> > It's our decision what we want to support and maintain in the code
> > base
> > and what we don't.
>
> That might be an argument in favor of custom auth methods, because we
> could
On Fri, Mar 4, 2022 at 6:03 PM Tatsuo Ishii wrote:
>
> >> I still don't understand why using plaintex password authentication
> >> over SSL connection is considered insecure. Actually we have been
> >> stating opposite in the manual:
> >> https://www.postgresql.org/docs/14/auth-password.html
> >>
On Wed, 2022-03-02 at 10:54 -0500, Stephen Frost wrote:
> It's our decision what we want to support and maintain in the code
> base
> and what we don't.
That might be an argument in favor of custom auth methods, because we
could move built-in methods that we don't like into a contrib module
that
>> I still don't understand why using plaintex password authentication
>> over SSL connection is considered insecure. Actually we have been
>> stating opposite in the manual:
>> https://www.postgresql.org/docs/14/auth-password.html
>>
>> "If the connection is protected by SSL encryption then
On Thu, 2022-03-03 at 11:12 +0100, Peter Eisentraut wrote:
> At the moment, it is not possible to judge whether the hook interface
> you have chosen is appropriate.
>
> I suggest you actually implement the Azure provider, then make the hook
> interface, and then show us both and we can see what
On Thu, Mar 3, 2022 at 11:50 PM Tatsuo Ishii wrote:
>
> >> So, dropping plaintext password authentication support from libpq will
> >> make it impossible for users to use the former method.
> >
> > Yes, just like dropping support for md5 would make it impossible for
> > users to have their
>> So, dropping plaintext password authentication support from libpq will
>> make it impossible for users to use the former method.
>
> Yes, just like dropping support for md5 would make it impossible for
> users to have their passwords be hashed with md5, which is an altogether
> good thing
On Thu, Mar 3, 2022 at 12:38:32PM -0500, Jonathan Katz wrote:
> On 3/3/22 12:23 PM, Bruce Momjian wrote:
> > On Thu, Mar 3, 2022 at 10:45:42AM +0100, Peter Eisentraut wrote:
> > > On 02.03.22 16:45, Jonathan S. Katz wrote:
> > > > By that argument, we should have kept "password" (plain) as an
>
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 02.03.22 21:49, samay sharma wrote:
> >I think we are discussing two topics in this thread which in my opinion
> >are orthogonal.
> >
> >(a) Should we make authentication methods pluggable by exposing these
> >hooks? -
On 3/3/22 12:23 PM, Bruce Momjian wrote:
On Thu, Mar 3, 2022 at 10:45:42AM +0100, Peter Eisentraut wrote:
On 02.03.22 16:45, Jonathan S. Katz wrote:
By that argument, we should have kept "password" (plain) as an
authentication method.
For comparison, the time between adding md5 and removing
Greetings,
* Tatsuo Ishii (is...@sraoss.co.jp) wrote:
> > Yes, really, it's a known-broken system which suffers from such an old
> > and well known attack that it's been given a name: pass-the-hash. As
> > was discussed on this thread even, just the fact that it's not trivial
> > to break on the
On Thu, Mar 3, 2022 at 10:45:42AM +0100, Peter Eisentraut wrote:
> On 02.03.22 16:45, Jonathan S. Katz wrote:
> > By that argument, we should have kept "password" (plain) as an
> > authentication method.
>
> For comparison, the time between adding md5 and removing password was 16
> years. It
Greetings,
* Tatsuo Ishii (is...@sraoss.co.jp) wrote:
> > On 2/25/22 12:39 PM, Tom Lane wrote:
> >> Jeff Davis writes:
> >>> On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:
> ... and, since we can't readily enforce that the client only sends
> those cleartext passwords over
On Thu, Mar 3, 2022 at 4:45 AM Peter Eisentraut
wrote:
>
> On 02.03.22 16:45, Jonathan S. Katz wrote:
> > By that argument, we should have kept "password" (plain) as an
> > authentication method.
>
> For comparison, the time between adding md5 and removing password was 16
> years. It has been 5
On 02.03.22 21:49, samay sharma wrote:
I think we are discussing two topics in this thread which in my opinion
are orthogonal.
(a) Should we make authentication methods pluggable by exposing these
hooks? - These will allow users to add plugins of their own to support
whatever auth method
On 02.03.22 15:16, Jonathan S. Katz wrote:
What are the reasons they are still purposely using it? The ones I have
seen/heard are:
- Using an older driver
- On a pre-v10 PG
- Unaware of SCRAM
Another reason is that SCRAM presents subtle operational issues in
distributed systems. As someone
On 02.03.22 16:45, Jonathan S. Katz wrote:
By that argument, we should have kept "password" (plain) as an
authentication method.
For comparison, the time between adding md5 and removing password was 16
years. It has been 5 years since scram was added.
On 02.03.22 21:26, Stephen Frost wrote:
Part of the point, for my part anyway, of dropping support for plaintext
transmission would be to remove support for that from libpq, otherwise a
compromised server could still potentially convince a client to provide
a plaintext password be sent to it.
On Wed, Mar 02, 2022 at 11:15:28AM -0500, Stephen Frost wrote:
> With... which? We removed recovery.conf without any warning between
> major releases, yet it was used by every single PG file-based backup and
> restore solution out there and by every single organization that had
> ever done a
> Yes, really, it's a known-broken system which suffers from such an old
> and well known attack that it's been given a name: pass-the-hash. As
> was discussed on this thread even, just the fact that it's not trivial
> to break on the wire doesn't make it not-broken, particularly when we
> use
> On 2/25/22 12:39 PM, Tom Lane wrote:
>> Jeff Davis writes:
>>> On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:
... and, since we can't readily enforce that the client only sends
those cleartext passwords over suitably-encrypted connections, this
could easily be a net negative
Hi,
On 2022-03-02 15:26:32 -0500, Stephen Frost wrote:
> Part of the point, for my part anyway, of dropping support for plaintext
> transmission would be to remove support for that from libpq, otherwise a
> compromised server could still potentially convince a client to provide
> a plaintext
Hi,
On Wed, Mar 2, 2022 at 12:32 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 01.03.22 22:34, Andres Freund wrote:
> > The cases I've heard about are about centralizing auth across multiple
> cloud
> > services. Including secret management in some form. E.g. allowing an
>
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-02 09:32:26 +0100, Peter Eisentraut wrote:
> > On 01.03.22 22:34, Andres Freund wrote:
> > > The cases I've heard about are about centralizing auth across multiple
> > > cloud
> > > services. Including secret management in some
Hi,
On 2022-03-02 09:32:26 +0100, Peter Eisentraut wrote:
> On 01.03.22 22:34, Andres Freund wrote:
> > The cases I've heard about are about centralizing auth across multiple cloud
> > services. Including secret management in some form. E.g. allowing an
> > application to auth to postgres, redis
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 2, 2022 at 10:54:27AM -0500, Stephen Frost wrote:
> > It's our decision what we want to support and maintain in the code base
> > and what we don't. Folks often ask for things that we don't or won't
> > support and this isn't
On Wed, Mar 2, 2022 at 10:54:27AM -0500, Stephen Frost wrote:
> It's our decision what we want to support and maintain in the code base
> and what we don't. Folks often ask for things that we don't or won't
> support and this isn't any different from that. We also remove things
> on a rather
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 2, 2022 at 10:29:45AM -0500, Stephen Frost wrote:
> > We don't require SSL to be used with them..? Further, as already
> > discussed on this thread, SSL only helps with on-the-wire, doesn't
> > address the risk of a compromised
On Wed, Mar 2, 2022 at 10:29:45AM -0500, Stephen Frost wrote:
> We don't require SSL to be used with them..? Further, as already
> discussed on this thread, SSL only helps with on-the-wire, doesn't
> address the risk of a compromised server. LDAP, in particular, is
> terrible in this regard
On 3/2/22 10:30 AM, Stephen Frost wrote:
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
On 02.03.22 15:16, Jonathan S. Katz wrote:
I find that a lot of people are still purposely using md5. Removing it
now or in a year would be quite a disruption.
What are the
On Wed, Mar 2, 2022 at 10:29 AM Stephen Frost wrote:
>
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Wed, Mar 2, 2022 at 10:09:31AM -0500, Stephen Frost wrote:
> > > I'm not sure that it's quite so simple. Perhaps we should also drop
> > > LDAP and I don't really think PAM
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 02.03.22 15:16, Jonathan S. Katz wrote:
> >>I find that a lot of people are still purposely using md5. Removing it
> >>now or in a year would be quite a disruption.
> >
> >What are the reasons they are still purposely
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 2, 2022 at 10:09:31AM -0500, Stephen Frost wrote:
> > I'm not sure that it's quite so simple. Perhaps we should also drop
> > LDAP and I don't really think PAM was ever terribly good for us to have,
> > but at least PAM and
On 02.03.22 15:16, Jonathan S. Katz wrote:
I find that a lot of people are still purposely using md5. Removing
it now or in a year would be quite a disruption.
What are the reasons they are still purposely using it? The ones I have
seen/heard are:
- Using an older driver
- On a pre-v10
On Wed, Mar 2, 2022 at 10:09:31AM -0500, Stephen Frost wrote:
> I'm not sure that it's quite so simple. Perhaps we should also drop
> LDAP and I don't really think PAM was ever terribly good for us to have,
> but at least PAM and RADIUS could possibly be used with OTP solutions
> (and maybe
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Bruce Momjian (br...@momjian.us) wrote:
> >> What is the logic to removing md5 but keeping 'password'?
>
> > I don't think we should keep 'password'.
>
> I don't see much point in that unless we deprecate *all* the
Stephen Frost writes:
> * Bruce Momjian (br...@momjian.us) wrote:
>> What is the logic to removing md5 but keeping 'password'?
> I don't think we should keep 'password'.
I don't see much point in that unless we deprecate *all* the
auth methods that transmit a cleartext password.
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Mar 1, 2022 at 08:31:19AM -0500, Stephen Frost wrote:
> > > The last time I played with this area is the recent error handling
> > > improvement with cryptohashes but MD5 has actually helped here in
> > > detecting the problem as a
On Tue, Mar 1, 2022 at 08:31:19AM -0500, Stephen Frost wrote:
> > The last time I played with this area is the recent error handling
> > improvement with cryptohashes but MD5 has actually helped here in
> > detecting the problem as a patched OpenSSL would complain if trying to
> > use MD5 as hash
On 3/2/22 3:24 AM, Peter Eisentraut wrote:
On 01.03.22 22:17, Jonathan S. Katz wrote:
If you're moving to a newer version of PostgreSQL, you likely have to
update your connection drivers anyway (rebuilt against new libpq,
supporting any changes in the protocol, etc). I would prefer more data
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 01.03.22 22:34, Andres Freund wrote:
> >The cases I've heard about are about centralizing auth across multiple cloud
> >services. Including secret management in some form. E.g. allowing an
> >application to auth to
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-02-28 11:26:06 +0100, Peter Eisentraut wrote:
> > We already have a variety of authentication mechanisms that support central
> > management: LDAP, PAM, Kerberos, Radius.
>
> LDAP, PAM and Radius all require cleartext passwords, so
On 01.03.22 22:34, Andres Freund wrote:
The cases I've heard about are about centralizing auth across multiple cloud
services. Including secret management in some form. E.g. allowing an
application to auth to postgres, redis and having the secret provided by
infrastructure, rather than having to
On 01.03.22 22:17, Jonathan S. Katz wrote:
If you're moving to a newer version of PostgreSQL, you likely have to
update your connection drivers anyway (rebuilt against new libpq,
supporting any changes in the protocol, etc). I would prefer more data
to support that argument, but this is
Hi,
On 2022-02-25 13:40:54 -0500, Jonathan S. Katz wrote:
> On 2/25/22 12:39 PM, Tom Lane wrote:
> > My point is that sending cleartext passwords over the wire is an
> > insecure-by-definition protocol that we shouldn't be encouraging
> > more use of.
>
> This is my general feeling as well. We
Hi,
On 2022-02-28 11:26:06 +0100, Peter Eisentraut wrote:
> We already have a variety of authentication mechanisms that support central
> management: LDAP, PAM, Kerberos, Radius.
LDAP, PAM and Radius all require cleartext passwords, so aren't a great
solution based on the concerns voiced in this
On 2/28/22 5:26 AM, Peter Eisentraut wrote:
On 17.02.22 20:25, samay sharma wrote:
A use case where this is useful are environments where you want
authentication to be centrally managed across different services. This
is a common deployment model for cloud providers where customers like
to
On 3/1/22 8:31 AM, Stephen Frost wrote:
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote:
Keeping it around will just push out the point at which everyone will
finally be done with it, as there's really only two groups:
On Mon, Feb 28, 2022 at 03:46:34PM -0500, Stephen Frost wrote:
> md5 should be removed.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote:
> > Keeping it around will just push out the point at which everyone will
> > finally be done with it, as there's really only two groups: those who
> > have already moved to
On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote:
> Keeping it around will just push out the point at which everyone will
> finally be done with it, as there's really only two groups: those who
> have already moved to scram, and those who won't move until they want to
> upgrade to a
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > md5 should be removed.
>
> Really? I've always thought that the arguments against it were
> overblown for our use-case. At any rate, it's likely to be
> years before we could practically do that, since it's the best
Stephen Frost writes:
> md5 should be removed.
Really? I've always thought that the arguments against it were
overblown for our use-case. At any rate, it's likely to be
years before we could practically do that, since it's the best
that older client libraries can manage.
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Fri, 2022-02-25 at 14:10 -0500, Tom Lane wrote:
> > I also have in mind here that there has been discussion of giving
> > libpq a feature to refuse, on the client side, to send cleartext
> > passwords.
>
> I am generally in favor of that
Greetings,
* Jonathan S. Katz (jk...@postgresql.org) wrote:
> On 2/25/22 12:39 PM, Tom Lane wrote:
> >Jeff Davis writes:
> >>On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:
> >>>... and, since we can't readily enforce that the client only sends
> >>>those cleartext passwords over
On 17.02.22 20:25, samay sharma wrote:
A use case where this is useful are environments where you want
authentication to be centrally managed across different services. This
is a common deployment model for cloud providers where customers like to
use single sign on and authenticate across
On 28.02.22 00:17, Jeff Davis wrote:
I also have in mind here that there has been discussion of giving
libpq a feature to refuse, on the client side, to send cleartext
passwords.
I am generally in favor of that idea, but I'm not sure that will
completely resolve the issue. For instance, should
On Fri, 2022-02-25 at 14:10 -0500, Tom Lane wrote:
> I'm happy to add support for custom auth methods if they can use
> a protocol that's safer than cleartext-password. But if that's the
> only feasible option, then we're just encouraging people to use
> insecure methods.
FWIW, I'd like to be
Hi,
On 2022-02-25 14:10:39 -0500, Tom Lane wrote:
> I'm happy to add support for custom auth methods if they can use
> a protocol that's safer than cleartext-password. But if that's the
> only feasible option, then we're just encouraging people to use
> insecure methods.
It looks like scram can
On Fri, 2022-02-25 at 13:40 -0500, Jonathan S. Katz wrote:
> I'm generally in favor of being able to support additional
> authentication methods, the first one coming to mind is supporting OIDC.
> Having a pluggable auth infrastructure could possibly make such efforts
> easier. I'm definitely
Jeff Davis writes:
> On Fri, 2022-02-25 at 12:39 -0500, Tom Lane wrote:
>> My point is that sending cleartext passwords over the wire is an
>> insecure-by-definition protocol that we shouldn't be encouraging
>> more use of.
> We can require custom auth entries in pg_hba.conf to also specify
>
1 - 100 of 114 matches
Mail list logo
