Re: [HACKERS] Changing references of password encryption to hashing - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: [HACKERS] Changing references of password encryption to hashing |
Date | |
Msg-id | ZWbkVNEjuELoqJ4J@tamriel.snowman.net Whole thread Raw |
In response to | Re: [HACKERS] Changing references of password encryption to hashing (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: [HACKERS] Changing references of password encryption to hashing
|
List | pgsql-hackers |
Greetings, * Robert Haas (robertmhaas@gmail.com) wrote: > On Tue, Nov 28, 2023 at 12:24 PM Stephen Frost <sfrost@snowman.net> wrote: > > 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, > > That's EXACTLY right. You can't say whether LDAP is better or worse in > every scenario. And therefore you should not be proposing to remove > it. 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. Until more recently, an argument could be made that we needed to keep ldap around because pgAdmin didn't support Kerberos, but that's been addressed for a couple years now. At some point, once there aren't any good use-cases for it to be kept, we should remove it or at least deprecate and discourage its use, though as I suspect everyone already knows, I really don't like deprecating things because it means we just end up keeping them around forever. As I tried to get at in my prior response, we should be encouraging the use of secure options when they're available and that's something which I actively do, on these lists and in working with clients. That I continue to find cases of perfectly good AD deployments which could be using Kerberos but instead are using ldap is frustrating. What I don't understand is this push-back against even talking about the issues with ldap or appreciation that passing around cleartext passwords is a security issue (modern password-based authentication methods, like SCRAM, don't even do this anymore, because it's not a good idea). If my opinion that we should remove it is that offensive, then fine, let's drop that part of the discussion and move on to the question of: why are people still using ldap? I'm pretty sure the answer is that far too often people think that's just how you integrate PG into an AD environment- and they think it's either the only option or sometimes believe it's a secure option. We've had people claim on these lists that using ldap doesn't pass around cleartext passwords, which I suspect means that maybe they thought our 'ldap' auth was actually somehow doing Kerberos under the hood (I really wish it was, but sadly that's obviously not the case). For some users, the issue is that our Kerberos/pg_ident/et al system isn't as good as it could be in an AD environment, which is one of the things that I was trying to allude to in my prior reply. In particular, we don't currently have support for working with AD's ldap for what it was actually meant for, which is using it to query for information like group membership. There had been some work on this not too long ago but sadly I haven't seen recent activity around that. What I've heard requested are things like having an option to say "users in group X are allowed to log in to role Y", or "users in group X are allowed to log into database Z". Would also be great to have built-in support for syncing from ldap the list of users which should exist in PG (pg_ldap_sync does an alright job of this today but we could certainly do better by having it built-in, and ideally with a background worker that connects to ldap, does an initial sync, and then listens for changes, instead of having to have a frequent cronjob doing the sync). > >> 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 shouldbe applying for q CVE prior to each release, no? > > You know, I said in my previous email that you were so sure that you > were right that there was no point in trying to have a serious > discussion, and I can't really see how you could have proved that > point more thoroughly than you did here. You twisted my words around > to make it seem like I was agreeing with your point when you know full > well that I was doing the exact opposite of that. 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. I understand that you still don't want to remove md5 or ldap and I don't think anyone following this discussion would be confused in that. I do feel we do a disservice to our users to continue encouraging the use of either. Thanks, Stephen
Attachment
pgsql-hackers by date: