Date: Mon, 10 Aug 2015 15:40:59 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
 Michael Paquier <michael.paquier@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: SCRAM authentication
Message-ID: <20150810194059.GN3685@tamriel.snowman.net>
References: <55192AFE.6080106@iki.fi>
 <CAB7nPqRB_Z2B7Lz96iHbHUQBQLwmUtj64hXu0u7mMZjpSk8UUg@mail.gmail.com>
 <CAB7nPqRBtLOT=g3q2-uYE=NbBdtkLubvDbV6wfCUp3hubpa6dg@mail.gmail.com>
 <CA+TgmoZ0XxXZeGa0f1uwaCN-FCjFsAJZdJgioeesdhfR7jmEhg@mail.gmail.com>
 <55C4FCC2.3000503@iki.fi>
 <CAB7nPqRWYJmw+qJrawP=h2J5s6LFea3NUb10VJJjdBNr1Wz=+g@mail.gmail.com>
 <CA+TgmoazGS0TpAtrFw+ft1UVUevBBXew5Lo6b1jtozgykpy5PA@mail.gmail.com>
 <55C63B1E.2040101@iki.fi>
 <CA+TgmoYQ=8BR87xgGkEWs8HJSe3KQh5v4fq+bZ2SAZhAnH3MtQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="WoqaC9TUMqqIOlla"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoYQ=8BR87xgGkEWs8HJSe3KQh5v4fq+bZ2SAZhAnH3MtQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--WoqaC9TUMqqIOlla
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Sat, Aug 8, 2015 at 1:23 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrot=
e:
> > 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. SC=
RAM
> > uses verifier that's derived from the password in one way, MD5
> > authentication needs an MD5 hash, and yet other protocols have other
> > requirements.
>=20
> 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 s=
hould
> > adopt it.
>=20
> 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

--WoqaC9TUMqqIOlla
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJVyP5LAAoJEO1sijiDR2RVRW4P/3nB1ubGJ2XLdjn6/PO/JFMP
AOyGaGKjuwW1CzAVR2Gi0TWk3xGkV7ghJJm16qtnuOmqaUKfQ/j9GGnaGcmkUtZS
DSvC6wLJTNvxfbexZBe1yZaA5d8BrJFZ4ERVzuN/YF7Ln1copz/0U8AMXCFDj5mu
65+95kr/9w8LBs6Uov+Fdg1N+DlvJQKxmXtXPionBRyYQ1HIOdakCy0GWNizT/mX
pwpdsyGpeI5iBYkrP5dMyOMEbpo1OXfJVtm0TmLzxGdHZ1ZD4P5mVLXOTaVeDnPH
qwKLNdpMOBs41Znc1YyAWSPKji1/klIGrVLzCYD3v/k45b5eZB+5Oe8XEHHgEeix
4AJVd9A4/2NEP+OBreXw3gUl3GTvBSUN9Pnyp70FvsvKls8nFsrUVDpksmJguK1o
XG9hWc4+SDWW/Usai9Xw9zzrFl4dzUSvxVtjvEvLTT1MdNc6TgnDkWXOR2Dz96dz
Ru7t1yE9Xi7SGTK9p/5jkO7SJPPxRdyv9ekHbvl6Zm5fPxA9Rr1+8SDPqPXSieUr
nk87pOQBAyMM/R2gI3oBqky9DaxUm1959SS/93aOz1lQ7BGFHergr0AwbdHEtxcs
P+lE/5Swg3FVxMXTSsqT77b6+5DNDHjDFDOp3iBVJT3Fy5EDqVBt207E2Z1Cie0m
bD8Izar0fjgkAXwMgQIC
=9+4P
-----END PGP SIGNATURE-----

--WoqaC9TUMqqIOlla--