Re: WIP: SCRAM authentication

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Sat, Aug 8, 2015 at 1:23 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)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.

I agree with Josh that requiring a hard switch simply won't be
acceptable to our user community and if decide "there can only be one
running at a time" then we'll never get people to move off md5 and
therefore we wouldn't ever make real progress here. Apologies to Josh
if I've misconstrued anything in his excellent response.

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

Apologies for my incomplete up-thread definition of a password verifier,
it was a bit off-the-cuff while I was out of the country and referred to
the specific password verifier in SCRAM, which isn't a cleartext
or encrypted password or a simple hash of it, or a salted hash.

To flip it around as a positive definition instead of the negative "it's
not X, Y or Z" which I provided up-thread, a "password verifier" is a
general term for anything that can be used to verify that the client
knows the right password, so it technically could be the cleartext
version of the password, or a simple hash of the password, or an
encrypted version of the password, or pretty much anything else that
works for the protocol. The reason it came about was because of this
very issue that there wasn't a general term for the value- it was
referred to as a salted hash, or encrypted, or just hashed, etc, and
those terms don't apply to everything that can be used today as a
password verifier.

As such, it's actually correct usage in this case as it's a general
term, rather than the specific and incorrect term "encrypted" which we
have today.

Thanks!

Stephen