On Sat, Aug 8, 2015 at 1:23 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 08/08/2015 04:27 PM, Robert Haas wrote:
>> I don't see that there's any good reason to allow the same password to
>> be stored in the catalog encrypted more than one way,
>
> Sure there is. If you want to be able to authenticate using different
> mechanism, you need the same password "encrypted" in different ways. SCRAM
> uses verifier that's derived from the password in one way, MD5
> authentication needs an MD5 hash, and yet other protocols have other
> requirements.
Why do we need to be able to authenticate using more than one
mechanism? If you have some clients that can't support SCRAM yet, you
might as well continue using MD5 across the board until that changes.
You're not going to get much real security out of using MD5 for some
authentication attempts and SCRAM for other ones, and the amount of
infrastructure we're proposing to introduce to support that is pretty
substantial.
>> and I don't think there's any good reason to introduce the PASSWORD
>> VERIFIER terminology. I think we should store (1) your password,
>> either encrypted or unencrypted; and (2) the method used to encrypt
>> it. And that's it.
>
>
> Like Joe and Stephen, I actually find it highly confusing that we call the
> MD5 hash an "encrypted password". The term "password verifier" is fairly
> common in the specifications of authentication mechanisms. I think we should
> adopt it.
OK, but it sure looked from Michael's syntax description like you
wrote PASSWORD VERIFIER (md5 'the_actual_password'). Or at least
that was my impression from reading it, maybe I got it wrong. If you
want to introduce ALTER USER ... PASSWORD VERIFIER as alternative
syntax for what we now call ALTER USER ... ENCRYPTED PASSWORD, that
works for me. But a plaintext password shouldn't be called a password
verifier under the terminology you are using here, IIUC.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
