Re: [HACKERS] password_encryption, default and 'plain' support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] password_encryption, default and 'plain' support
Date
Msg-id 1088.1493833200@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] password_encryption, default and 'plain' support  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [HACKERS] password_encryption, default and 'plain' support  (Heikki Linnakangas <hlinnaka@iki.fi>)
List 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



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: [HACKERS] renaming "transaction log"
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] WITH clause in CREATE STATISTICS