From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-27 23:17:44 |
Message-ID: | 9004b18218eae293f1ee888e49d13d8a6b02810d.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2022-02-25 at 14:10 -0500, Tom Lane wrote:
> 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.
FWIW, I'd like to be able to use a token in the password field, and
then authenticate that token. So I didn't intend to send an actual
password in plaintext.
Maybe we should have a new "token" connection parameter so that libpq
can allow sending a token plaintext but refuse to send a password in
plaintext?
> 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 am generally in favor of that idea, but I'm not sure that will
completely resolve the issue. For instance, should it also refuse MD5?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-02-28 00:00:26 | Re: Missed condition-variable wakeups on FreeBSD |
Previous Message | Tom Lane | 2022-02-27 22:24:48 | Re: Missed condition-variable wakeups on FreeBSD |