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
-
Remove support for password_encryption='off' / 'plain'.
- eb61136dc75a 10.0 landed