Re: [HACKERS] Changing references of password encryption to hashing - Mailing list pgsql-hackers

On Wed, Nov 29, 2023 at 2:12 AM Stephen Frost <sfrost@snowman.net> wrote:
> I had been hoping you might shed some light on just what use cases you
> were referring to so that we could have a constructive discussion about
> if ldap is actually a reasonable solution.  I even explicitly pointed
> out that there may still exist some environments, such as those with
> OpenLDAP only and which don't have Kerberos that could be a valid reason
> to keep ldap, but I haven't heard of any such in quite a long time.

I mean, I just have a hard time seeing this as a serious discussion. I
can't believe a proposal to remove LDAP authentication would reach
consensus for any reason other than because people didn't notice the
discussion or didn't want to argue about it, and I'm sure we'd have
unhappy users later. I don't want to spend a huge amount of time
arguing over something that I think is fairly obviously a non-viable
idea. If I'm wrong and a whole bunch of people show up and say they
like it, well, then I'm wrong. But either way, literally nobody wants
to read 100 emails where you and I go around in circles. And I don't
want to write them, either.

That said, I think that the case you mention, where someone has only
LDAP and not AD, is one example of where you would want LDAP
authentication. And really, that ought to end discussion of the topic,
because surely that is a valid use case, and we don't typically remove
features that someone might find useful because one hacker suggests
it. But in my experience, that's actually missing the point
completely. The most common complaint that I see from users about
authentication goes like this:

"I have log_statement=all enabled and so every time a user changes
their password the new password ends up in plaintext in the log file
and that means PostgreSQL is insecure."

I want to make it clear that, number one, this is not a joke, and,
number two, this is not the only concern that regularly reaches me
which reflects this degree of failing to understand how to set up a
secure environment. It's just an example of the level that many people
are apparently at. You're talking about removing authentication
methods because they have subtle, conditional security hazards, but a
lot of people are still running systems with flagrant, hideous
security hazards. Making it harder for such a user to store passwords
outside the database, or making them feel like that's somehow bad or
insecure when what they're doing instead is WAY worse, is not the
right thing at all.

I'd fully support having good documentation that says "hey, here are
the low security authentication configurations, here are the
medium-security ones, here are the high security ones, and here's why
these ones are better than those ones and what they protect against
and what risks remain." That would be awesome. But I'm not in favor of
removing options. We don't know where any particular user is coming
from today, and as in the example above, it might be something REALLY
bad. Moreover, users are entitled to make prudential judgments about
which things they care about in practice. They're allowed to say "hey,
yeah, so LDAP has this weakness if the server gets suborned, but I
don't care about that because of X reason," just as they're allowed to
accept the risks of any other authentication method, including trust.
Some of the reasons people might have for accepting such risks are
doubtless extremely strong, like "it's a physically disconnected
network" or "this is a burner setup that I'm tearing down tomorrow and
will contain only non-critical data anyway," and others are doubtless
poor reasons where users take inappropriate risk. But removing
everything from PostgreSQL that can be used to hose yourself is not a
viable strategy, and it's also not right for us to try to substitute
our judgement about what is appropriate in a particular user's
environment for that user's own judgement, especially if they're
right, but even if they're wrong. We're here to provide software, not
compel obedience.

> I quoted the part where you agreed that md5 has a known vulnerability to
> point out that, given that, we should be making our users aware of that
> through the normal process that we use for that.  I wasn't claiming that
> you agreed that we should remove md5, unless you're referring to some
> other part of my response which you didn't quote, in which case it'd be
> helpful if you could clarify which you were referring to so that I can
> try to clarify.

You made it sound like I supported what you wanted to do when you knew
I didn't. That's a poor foundation for any kind of reasonable
discussion of alternatives.

--
Robert Haas
EDB: http://www.enterprisedb.com