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