Date: Tue, 18 Aug 2015 10:06:37 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Josh Berkus <josh@agliodbs.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter_e@gmx.net>,
 Heikki Linnakangas <hlinnaka@iki.fi>,
 Michael Paquier <michael.paquier@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: SCRAM authentication
Message-ID: <20150818140637.GI3685@tamriel.snowman.net>
References: <55CB5D38.5090503@gmx.net>
 <CA+TgmoZq6T=jsEr5sAW5Q3_63E4zaoim918e5fkb187AVmhr2g@mail.gmail.com>
 <55CBA425.5070803@gmx.net>
 <20150812200938.GM3685@tamriel.snowman.net>
 <CA+TgmoYRkGAYC8XAz91qiwDK=wEqXgUbCoaPgiZDnde0cMSj5Q@mail.gmail.com>
 <20150812203732.GN3685@tamriel.snowman.net>
 <CA+Tgmob0T6MgQZ2fFityAsyXiX-rni0hU=LVtaFUv0oo7cdz2w@mail.gmail.com>
 <20150813013607.GS3685@tamriel.snowman.net>
 <WM!f47f2028fc1867e14926553022b78cd909807c8421cfe79fc83dece946e5dacb3c67bbaa75c363e878fc83c4680f7899!@asav-1.01.com>
 <55CCE12B.4030306@agliodbs.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="L3Y4E/NjQRvmPTLz"
Content-Disposition: inline
In-Reply-To: <55CCE12B.4030306@agliodbs.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--L3Y4E/NjQRvmPTLz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Josh,

* Josh Berkus (josh@agliodbs.com) wrote:
> I don't feel like you've correctly assessed the risk inherent in the
> md5 auth method, which is that, having captured an md5auth string by
> whatever means, and attacker can reuse that md5 string on other
> databases in the network *without* cracking it.  That's the biggest risk
> as long as md5 is present.

Robert and I, I believe, are both aware of that risk and had moved on to
discussing the risk to the cleartext password by keeping an md5 present,
even if it wasn't able to be used for login.  We will want to make it
simple for admins to enable/disable md5 (eg: pg_hba), but we also have
to consider how to make it simple for admins to remove the old md5
password verifier or there will be risk of the cleartext password being
compromised from backups, etc.

I fully agree that it's a serious risk that, today, what's stored in the
database is directly usable for logging into the running system (or any
system where the user has the same username and password).

> Aside from code complexity, the user security concern with a "multiple
> verifier per role" approach is that the DBAs would never remember to
> completely disable md5auth and would capture md5 hashes either in flight
> or from backups.  This approach can be used to capture an md5hash from a
> non-critical database which is poorly secured, and then re-use it
> against an important database.

The 'in flight' case is at least a bit less of an issue, as we don't
ship the password verifier directly over the network.  The backup
concern is certainly corret though.  I fully agree that we need a way to
make sure users don't end up having the old password verifiers around
longer than necessary.

That was the imputus for my earlier suggestion that in a release or two,
we actively make pg_upgrade error (or perhaps warn first, then error,
across two releases) if any of the old verifiers exist.

> Now, the counter-argument to this is that a DBA is just as likely to
> rememeber to remove md5 verifiers as she is to remember to remove roles
> with md5auth.

Indeed, that's a serious concern also.

The other concern with a single password verifier is that we're locking
ourselves into a one-verifier-per-role solution when most of the serious
solutions in use today (Active Directory, Kerberos, certificate based
systems) allow for more than one.

> Regardless of the approach we take, encouraging users to migrate is
> going to be more of a matter of documentation, publicity, and
> administrative tools than one of multiple verifiers vs. multiple roles.
>  That is, giving DBAs the ability to see and log who's using what kind
> of verifier, and what account has what verifier(s) available, will make
> more of a difference.

Fully agreed.

	Thanks!

		Stephen

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

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

iQIcBAEBCgAGBQJV0zvsAAoJEO1sijiDR2RVDGUQALTmz+SFUA48tZYeTLmwp6En
y+ISIdiDhHaqSAA7C0Tb8Y/L6TG9KiNiRSS6dDzzn3wvt4StviKIOhyK6MPHJCVp
G9DbAncR5N+KF9qvN0JGU/zlzKc+3tZoYLpmsHssnb2cEdbDVd57i6Q1cIGddUm8
uY8QtmRApu5B4e5tpSHv4KbQEWLfyMWWFjLaFOnlUfo6vg5SfGMUrMspTVZbJFMW
OX5T7eYOM8H63K725s/5M7vYUNVjXOIZvKHAXsqjDuCxqFH6Hnk68KkW9SyRR25B
JHkG+yJrteu7KfCS375qcxbmtvCwGKjNDAwWRGF23Y7S5+7PuBC4w8aHteaZGuUF
nZYIweAnyxHGppFKNZEnc+WDq0AAnEyYZDgUNdA23yP9U2756rhu0rpN8TofXRWo
cudCkrBDdFIj4OXqU+vgnfs03GN4PxAametpGbrONfsz4o+LcpgkB0uuIFif8AtX
00/0Z5Wl5znthGMM6aXTL5YY8xhDBePDvQRBP5ts+lS/P0YeOnoVLLNOY0UEnaeK
XBwTmcYiVA5SnoTB+N4OEAXt19dcNb3qc/uI73IKbHPPvsfcWCxn9ACDf09mELhg
97NMRqoV8AYpzWyva5fk2/5ejvnr55n6Rvd1qs1zSiEl3We/MTB+kIv5z8xhWxaR
Jh7IIe+QO2dKZBwxeDX4
=b1iY
-----END PGP SIGNATURE-----

--L3Y4E/NjQRvmPTLz--