|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||"Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, samay sharma <smilingsamay(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Subject:||Re: Proposal: Support custom authentication methods using hooks|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Thu, Mar 3, 2022 at 12:38:32PM -0500, Jonathan Katz wrote:
> On 3/3/22 12:23 PM, Bruce Momjian wrote:
> > On Thu, Mar 3, 2022 at 10:45:42AM +0100, Peter Eisentraut wrote:
> > > On 02.03.22 16:45, Jonathan S. Katz wrote:
> > > > By that argument, we should have kept "password" (plain) as an
> > > > authentication method.
> > >
> > > For comparison, the time between adding md5 and removing password was 16
> > > years. It has been 5 years since scram was added.
> > Uh, when did we remove "password". I still see it mentioned in
> > pg_hba.conf. Am I missing something?
> I may have explained this wrong. The protocol still supports "plain" but we
> removed the ability to store passwords in plaintext:
> "Remove the ability to store unencrypted passwords on the server
> "The password_encryption server parameter no longer supports off or plain.
> The UNENCRYPTED option is no longer supported in CREATE/ALTER USER ...
> PASSWORD. Similarly, the --unencrypted option has been removed from
> createuser. Unencrypted passwords migrated from older versions will be
> stored encrypted in this release. The default setting for
> password_encryption is still md5."
OK, that does make sense.
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
If only the physical world exists, free will is an illusion.
|Next Message||Robert Haas||2022-03-03 18:11:17||Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:|
|Previous Message||Andres Freund||2022-03-03 17:50:22||Re: casting operand to proper type in BlockIdGetBlockNumber|