Re: password_encryption, default and 'plain' support

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-05-03T17:40:00Z
Lists: pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 05/03/2017 07:14 PM, Tom Lane wrote:
>> Is it possible that there are still client libraries that don't support
>> password encryption at all?  If so, are we willing to break them?
>> I'd say "yes" but it's worth thinking about.

> That doesn't make sense. The client doesn't even know what 
> password_encryption is set to. I think you're confusing 
> password_encryption='plain' with the plaintext "password" authentication 
> method.

Ah, you're right.

> If the server has an MD5 hash stored in pg_authid, the server will ask 
> the client to do MD5 authentication. If the server has a SCRAM verifier 
> in pg_authid, it will ask the client to do SCRAM authentication. If the 
> server has a plaintext password in pg_authid, it will also ask the 
> client to do SCRAM authentication (it could ask for MD5 authentication, 
> but as the code stands, it will ask for SCRAM).

Um.  That would be a backwards compatibility break ... but it doesn't
matter if we get rid of the option to store in plaintext.

The other question I can think to ask is what will happen during
pg_upgrade, given an existing installation with one or more passwords
stored plain.  If the answer is "silently convert to MD5", I'd be
good with that.

			regards, tom lane


Commits

  1. Remove support for password_encryption='off' / 'plain'.