Re: [HACKERS] Changing references of password encryption to hashing

Greetings,

On Tue, Nov 28, 2023 at 20:19 Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Nov 28, 2023 at 10:16 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > 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.
>
> Good grief. I really think you need to reassess your approach to this
> whole area. It is massively unhelpful to be so prescriptive about what
> people are, or are not, allowed to be comfortable with from a security
> perspective. And it seems like you're so convinced that you're right
> that you're completely closed off to anyone else's input, so there's
> not even any point in arguing.

You asked what the issue is with our ldap auth method. I explained it
pretty clearly. Is there something incorrect about the issues I’ve pointed
out with ldap auth? You basically came back at me saying that I’m being
unhelpful for responding with what the issues are.

In the reality I inhabit, many people could *massively* improve their
> security by switching to LDAP from the really lame things that they're
> doing right now. They would be FAR better off. It would not even be
> close. I pretty much know that you aren't going to believe that and
> are going to offer reasons why it isn't and can't possibly be true, or
> else just say that those people are so hopeless that we shouldn't even
> care about them. All I can say is that you're worrying about security
> problems that are so minute as to be invisible compared to what I see.

I don’t know what they’re doing now, as you don’t say, and so I really
couldn’t say if ldap is better or worse for them. In some cases, sure,
perhaps ldap is better than … something else, but in 99% of cases, ldap is
being used because it seems simpler than setting up GSSAPI … but that’s a
lack of clearer documentation on our side on how to set up GSSAPI with AD
and PG, imv. I’ve tried to improve on that situation by explaining
clearly how to set up GSSAPI authentication with AD and then consistently
pointing people to that. I don’t put this out there as fiat without any
effort behind it, I’ve been working to move folks in the right direction,
I’ve put in that effort on the lists and continue to do so, feel free to
review the archives.

What I don’t understand is the argument for using ldap in an AD environment
instead of GSSAPI/sspi. Is there some reason you feel makes ldap better?
When there are two such options and one is clearly much more secure,
shouldn’t we push people to the more secure option… possibly even to the
exclusion and removal of the insecure option? Ditto below for md5 …

> 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).
>
> I agree that the issues with MD5 are way worse than the ones with
> LDAP, but you're arguing here, as you did with exclusive backup mode,
> that the existence of options that are bad, or that you consider to be
> bad, is a problem even if nothing whatever compels people to use them.

I’m not impressed with the conflation of this discussion and that of
exclusive backup mode. I wasn’t the one who deprecated exclusive backup
mode, tho I did agree with that move, and the reason for removing it was as
much about the complications of documenting it as for the fact that it was
actively broken.

I think that is, to borrow a phrase from Tom, arrant nonsense. Sure,
> MD5 authentication has a pass-the-hash vulnerability, and that sucks.

So, given that we all agree with the CVE-worthy issue that exists with
every release where we include md5 auth, we should be applying for q CVE
prior to each release, no?

So let's say we remove it. Then presumably we should also remove
> password authentication, which has an even easier-to-exploit
> vulnerability, and trust, which is easier to exploit still. And
> presumably it would be right to do all of that even if SCRAM
> authentication had never been implemented, so then we'd have no
> support for any form of password authentication at all. And we'd
> remove LDAP, too, so the most obvious way of doing password
> authentication without putting the passwords in the database would
> also not exist any more. Maybe we should nuke a few more too --- is
> PAM any better than LDAP in this regard? Pretty soon you end up in a
> world where it's either impossible to log into the database at all, or
> everybody's got to use, I don't know, Kerberos and SSL certificates,
> or something.

This is jumping to places that just don’t exist and I don’t really
understand why.

I didn’t ask for md5 to be removed before we had SCRAM. I was here, I knew
about the issues with md5, but, no, I didn’t push for us to remove it, so
this argument that I’m being ridiculous to ask for it to be removed now
doesn’t hold any water.

We do have a much better solution now and therefore, after a number of
years of supporting both, it’s time to remove the CVE-worthy auth method.
Yes, password and PAM and trust have issues. We should consider removing
them. Why didn’t I list them? Because they don’t have alternatives
immediately available (scram in place of md5, GSSAPI in place of ldap). We
could make an argument for removing password given that we have scram and I
would be for that but it’s at least a bit better understood why it’s bad
out there- I don’t feel like folks generally realize the md5 issue that we
have because that was deprecated and removed or not implemented for most
other systems long, long ago. For trust … I’d be a lot happier if we only
enabled that in debug-enabled builds or when explicitly requested for a
build.

But what will happen in practice is that either users will just give
> up on PostgreSQL because it refuses to let them do what they want to
> do, or those SSL certificates will end up unencrypted in a
> world-writable file somewhere, or get emailed around to everyone in
> the group, or maybe checked into the application's git repository that
> is public to the whole company behind the firewall. There won't be a
> passphrase on the certificate, or it will be set to 'secret123', or
> whatever. The expiration date will be set to the furthest date in the
> future that the software supports, or the user won't realize they need
> to worry about that and the application will suddenly go down when the
> certificate expires.

When the goal is “authenticate to our AD environment”, asking users to go
through a different path, eg: GSSAPI, to get that has been generally
successful in my experience, both on our lists and with our direct clients.
So, no, in my experience it isn’t that people give up on PG or switch to
using client side certs that are just distributed around with weak
passwords. More frequently users are very happy to go with the better
solution and they just didn’t realize it was available to them.

I don’t mean to imply that it’s perfect though- there are clear things we
could do to improve the situation and if folks want to discuss that, I’m
all about it. I’m happy to even be told that we need xyz support before we
remove ldap as an auth method, that’s fine, I’ll work to make that happen,
but to claim that we should keep ldap support for ldap support’s usage in
an AD environment … sorry, but no. Even Microsoft tried at one point to
prevent people from using it that way- they had to back off that position
eventually in terms of the default, but good AD admins are aware of the
distinction and will push back against new systems being deployed with it.

You can't make people do the right thing by removing their options.
> You can only make them work a little harder to get around the security
> control that you tried to impose by fiat, and in the process, make
> them frustrated. I imagine that the reason you didn't suggest removing
> 'trust' is that you admit the existence of environments where it's
> safe enough -- someone working with a local PG on a loopback port on a
> single-user machine, maybe a connection from a certain IP where that
> IP and the DB are both behind a firewall, or a burner system that
> someone just literally doesn't care about. But the "safe enough"
> argument applies to everything else, too. It's the job of users to
> adequately secure their systems against external attack, and it's our
> job to help them, not to enforce our own views on them. It is
> absolutely fine to tell users, in a thoughtful and balanced way, what
> the advantages and disadvantages of different choices are. But
> removing their choices is high-handed and ineffective.

I didn’t suggest removing trust directly because there isn’t a directly
comparable already available better alternative. I do think it should be a
bit harder for folks to use because too often they don’t realize what
they’re doing when they enable it, but I appreciate that’s a different
issue.

To parallel it to a recent change- I view it like force_parallel_mode. It
was useful for debugging and testing and perhaps still is, but we should
make it clear that it’s really intended just for that.

If asking users to work just a bit harder means that we get a good chunk of
them over to GSSAPI and off of ldap … then that is a moving us into a
clearly better position.

I’ll even accept, as others have pushed at me, that maybe we should keep
ldap because some folks still use PG with just openldap (and no Kerberos
environment), but it’s been an awful long time since anyone has even tried
to broach that argument and that’s not what is going on here, afaict anyway.

(Replying from my phone and perhaps not as concise or clear as I could be,
sorry about that, but am traveling and otherwise there would be quite an
additional delay..)

Thanks!

Stephen

>