Date: Wed, 4 Mar 2015 12:43: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: <20150304174354.GC29780@tamriel.snowman.net>
References: <20150304020146.GD24063@momjian.us>
 <20150304155230.GW29780@tamriel.snowman.net>
 <20150304173059.GF23933@momjian.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="koElQQqmLVmRs57w"
Content-Disposition: inline
In-Reply-To: <20150304173059.GF23933@momjian.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--koElQQqmLVmRs57w
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 10:52:30AM -0500, Stephen Frost wrote:
> > The first is a "don't break anything" approach which would move the
> > needle between "network data sensitivity" and "on-disk data sensitivity"
> > a bit back in the direction of making the network data more sensitive.
> >=20
> > this approach looks like this: pre-determine and store the values (on a
> > per-user basis, so a new field in pg_authid or some hack on the existing
> > field) which will be sent to the client in the AuthenticationMD5Password
> > message.  Further, calculate a random salt to be used when storing data
> > in pg_authid.  Then, for however many variations we feel are necessary,
> > calculate and store, for each AuthenticationMD5Password value:
> >=20
> > md5_challenge, hash(salt || response)
> >=20
> > We wouldn't store 4 billion of these, of course, which means that the
> > challenge / response system becomes less effective on a per-user basis.
> > We could, however, store X number of these and provide a lock-out
> > mechanism (something users have asked after for a long time..) which
> > would make it likely that the account would be locked before the
> > attacker was able to gain access.  Further, an attacker with access to
> > the backend still wouldn't see the user's cleartext password, nor would
> > we store the cleartext password or a token in pg_authid which could be
> > directly used for authentication, and we don't break the wireline
> > protocol or existing installations (since we could detect that the
> > pg_authid entry has the old-style and simply 'upgrade' it).
>=20
> What does storing multiple hash(password || stoarage_salt) values do for
> us that session_salt doesn't already do?

By storing a hash of the result of the challenge/response, we wouldn't
be susceptible to attacks where the user has gained access to the
contents of pg_authid because the values there would not be (directly)
useful for authentication.  Today, an attacker can take what's in
pg_authid and directly use it to authenticate (which is what the
interwebs are complaining about).

We wouldn't want to do that for just a single value though because then
there wouldn't be any value to the challenge/response system (which is
intended to prevent replay attacks where the attacker has sniffed a
value from the network and then uses that value to authenticate
themselves).

The only way we can keep the session salt random without breaking the
wireline protocol is to keep the raw data necessary for authentication
in pg_authid (as we do now) since we'd need that information to recreate
the results of the random session salt+user-hash for comparison.

This is essentially a middle ground which maintains the existing
wireline protocol while changing what is in pg_authid to be something
that an attacker can't trivially use to authenticate.  It is not a
proper solution as that requires changing the wireline protocol (or,
really, extending it with another auth method that's better).

	Thanks,

		Stephen

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

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

iQIcBAEBCgAGBQJU90RaAAoJEO1sijiDR2RVbvMQALBImD8+4PG/QNnvhkSnM+sn
n53Og5Q4o7abLUHN5GDDbIprRqPgWh5swYVZju4o3IHD/2wKiSzsOfhoMF9UR5/E
jQwEAXBC01XrtUr6TJAycnxoyt0Zyl4orOE9eJRB6sSFWspHfXz4Zm9IUNijHW8n
TKr1uxXgALF3ix7eqxxgQJut3Wx7jURRcjLtn3g7xlVLxIYKZWd5NExy7bLuwpOL
jGAQzIVZ5aoAv7lWmfNiAzhtBtK6LW88lGgH3v+s5zRROFX+2bvOZqnQT6mNdbgY
92tsZ6We99G4ZNHx/y6Jgu2tA543HUoqKi34EaeXPBdHy9lnHGnSvA3ik7jdSMGB
Sfl8EYXNXHOsy/IepPFW+uaPtes3CuZI0sN0jp9dRXDvwf0VLWZsPNgiYixEYqDr
W3hi+FwYk3eqTdpA3IfPX/YrAH6ADLEwl+TU8Jdn010x8xo9Ypyz1pjBnxWEsF73
in9CJZbSKqOVfvWOxkgPXfw67La6RfiJcSXbqkSfrnhv2IDBG3q6novatvNeV5Ce
IcBGNP9hccZ+aKHipvQUD6oaUZdgDRBIguC2J3DZHw3GAOknaBZFB8hEpW4WqrO9
t7WqK1irYZ13ICAGYNJ//6Aa2FV+M/hNoEPgL1+THvQXvVpvO60S1xR+McG/h98i
fLFpoDXDo/90mwApNiIh
=HPqd
-----END PGP SIGNATURE-----

--koElQQqmLVmRs57w--