Greetings,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Nov 28, 2023 at 9:55 AM Stephen Frost <sfrost@snowman.net> wrote:
> > I do think we should use the correct terminology in our documentation
> > and would support your working on improving things in this area.
>
> +1.
>
> > I do wonder if perhaps we would be better off by having someone spend
> > time on removing terribly insecure authentication methods like md5 and
> > ldap though ...
>
> Wait, what's insecure about LDAP?
We pass a completely cleartext password to the server from the client.
Yes, we might encrypt it on the way with TLS, but even SSH realized how
terrible that is long, long ago and strongly discourages it these days.
The problem with ldap as an auth method is that a single compromised PG
server in an AD/ldap environment can collect up those username+password
credentials and gain access to those users *domain* level access. The
CFO logging into a PG server with LDAP auth is giving up their complete
access credentials to the entire AD domain. That's terrible.
> I think we should eventually remove MD5, but I think there's no rush.
I disagree- it's a known pass-the-hash vulnerability and frankly every
release we do with it still existing is deserving of an immediate CVE
(I've been asked off-list why we don't do this, in fact).
> People who care about security will have already switched, and people
> who don't care about security are not required to start caring.
I wish it were this simple. It's just not though.
> Eventually the maintenance burden will become large enough that it
> makes sense to phase it out for that reason, but I haven't seen any
> evidence that we're anywhere close to that point.
This seems to invite the idea that what people who care about this need
to do is make it painful for us to continue to keep it around, which I
really don't think is best for anyone. We know it's bad, we know it is
broken, we need to remove it, not pretend like it's not broken or not
bad.
Thanks,
Stephen
