Date: Wed, 4 Mar 2015 14:46:54 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: MD5 authentication needs help
Message-ID: <20150304194654.GL29780@tamriel.snowman.net>
References: <20150304020146.GD24063@momjian.us>
 <20150304155230.GW29780@tamriel.snowman.net>
 <20150304173059.GF23933@momjian.us>
 <20150304174354.GC29780@tamriel.snowman.net>
 <20150304175857.GA31979@momjian.us>
 <20150304182731.GG29780@tamriel.snowman.net>
 <20150304191625.GB31979@momjian.us>
 <20150304192151.GJ29780@tamriel.snowman.net>
 <20150304193715.GC31979@momjian.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="cgcPEDKc2RK7mT+z"
Content-Disposition: inline
In-Reply-To: <20150304193715.GC31979@momjian.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

* Bruce Momjian (bruce@momjian.us) wrote:
> On Wed, Mar  4, 2015 at 02:21:51PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (bruce@momjian.us) wrote:
> > > On Wed, Mar  4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> > > > This further makes what is sent over the network not directly
> > > > susceptible to a replay attack because the server has multiple valu=
es
> > > > available to pick for the salt to use and sends one at random to the
> > > > client, exactly how our current challenge/response replay-prevention
> > > > system works.  The downside is that the number of possible values f=
or
> > > > the server to send to prevent replay attacke is reduced from 2^32 t=
o N.
> > >=20
> > > OK, I understand now --- by not using a random session salt, you can
> > > store a post-hash of what you receive from the client, preventing the
> > > pg_authid from being resent by a client.  Nice trick, though going fr=
om
> > > 2^32 to N randomness doesn't seem like a win.
> >=20
> > You're only looking at it from the network attack vector angle where
> > clearly that's a reduction in strength.  That is not the only angle and
> > in many environments the network attack vector is already addressed with
> > TLS.
>=20
> Well, passwords are already addressed by certificate authentication, so
> what's your point?  I think we decided we wanted a way to do passwords
> without requiring network encryption.

It's completely unclear to me what you mean by "passwords are already
addressed by certificate authentication."  Password-based and
certificate-based authentication are two independent mechanisms
available today, and both can be used with TLS.  Certainly the more
common implementation that I've come across is password-based
authentication through the md5 mechanism with TLS.  There are few places
which actually use client-side certificate-based authentication but tons
which use TLS.

> > From the perspective of what everyone is currently complaining about on
> > the web, which is the pg_authid compromise vector, it'd be a huge
> > improvement over the current situation and we wouldn't be breaking any
> > existing clients, nor does it require having the postmaster see the
> > user's cleartext password during authentication (which is a common
> > argument against recommending the 'password' authentication method).
>=20
> We are not designing only for what people are complaining about today.

I was simply trying to explain what the 'newly discovered' vector
being discussed today is.  I complained about our implementation here 10
years ago and it has come up before this recent wave of complaints since
then, though perhaps with a bit less publicity, but I suspect that's
just because PG is getting popular.

And, no, I'm not suggesting that we design differently because we're now
popular, but I do think we need to address this issue because it's very
clearly an obvious deficiency.  I trust you feel the same as you started
this thread.

I brought up this approach because it avoids breaking the wireline
protocol or forcing everyone to switch to a new authentication method.

	Thanks,

		Stephen

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

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

iQIcBAEBCgAGBQJU92EuAAoJEO1sijiDR2RVy6gQALm/hmf65cO514l/FPlpZ2Xq
0OlHBvyCrSjz5+ocP/owKEnd7ogVk2Poxk98sjyowT0hXvWTWyAntfTCmJXRB+xz
7U0o/EQM0TUZ5YJzFLgu7GG/1Pv6XNO6UCv38C0uMK266aU29rj4AFQiYWS9kV/k
On9OA5DlPvAKhnNyG0i00d2g74mBY++nbU8vZiJuTX1T6dUG0vWtgQ9r0jyZAMr7
zlvVtZjxDCpL79QM9TYmdGd5AXAxLeq25rqw6PXO6KQ6XFrtK9cQcBbA9fEjbIfl
0XMfno5IIxqodr9KGRBauS0xsziGKvltO5TXwe2IJIIcY/tCdVNgrFFTYWyRocWM
LZCcieALbEq1nAdy45hBS6JRh2PAlEIKq5Km8dLBoSJn6QX1wpHuT3r7ACr65PKK
vc7vsylW+6PCkVYeBLhJTWUebCTuqhymWz53CsflrX0yNBSg+4FIvBYx+1PASUZR
SFMhI5JalCKisT6I+4vU0WymqqJquf5GpD1RKV/Zs2TbDvp1zhGm9MLkjBNlxgdW
OFLTuQpW0W5GZiC6fzcRsfuz1ljw5VRHdf/CrOuw6z3UeTQAmnj55A7QS8yShSZh
S2oHXbEpuxCMw8JNyVBNU2VSUw349OrfvxY7AC+sOehkpnX/sLrXGKLovA9lgX6H
qyQ7xOM2ZKW8GI8TxYk8
=YHgE
-----END PGP SIGNATURE-----

--cgcPEDKc2RK7mT+z--