From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | samay sharma <smilingsamay(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Proposal: Support custom authentication methods using hooks |
Date: | 2022-02-25 19:10:39 |
Message-ID: | 1980351.1645816239@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> 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
> local, hostssl or hostgssenc.
That's just a band-aid, though. It does nothing for the other
reasons not to want cleartext passwords, notably that you might
be giving your password to a compromised server.
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.
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 don't recall right now if that's been mentioned
publicly or only among the security team, but it's definitely
under consideration.)
So I think this proposal needs more thought. A server-side hook
alone is not a useful improvement IMO; it's closer to being an
attractive nuisance.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2022-02-25 19:25:01 | Re: Design of pg_stat_subscription_workers vs pgstats |
Previous Message | Nathan Bossart | 2022-02-25 19:04:35 | Re: Fix overflow in justify_interval related functions |