Re: password_encryption, default and 'plain' support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: password_encryption, default and 'plain' support
Date: 2017-05-03 17:40:00
Message-ID: 1088.1493833200@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-05-03 17:41:48 Re: WITH clause in CREATE STATISTICS
Previous Message Philippe BEAUDOIN 2017-05-03 17:36:58 Re: Column rename in an extension update script