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
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 |