Date: Thu, 28 May 2020 13:09:50 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Christoph Berg <myon@debian.org>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	Devrim =?iso-8859-1?B?R/xuZPx6?= <devrim@gunduz.org>,
	Craig Ringer <craig@2ndquadrant.com>,
	pgsql-pkg-yum <pgsql-pkg-yum@postgresql.org>
Subject: Re: Can we stop defaulting to 'md5'?
Message-ID: <20200528170950.GB6680@tamriel.snowman.net>
References: <20200520163509.GG3418@tamriel.snowman.net>
 <20200520153337.GE3418@tamriel.snowman.net>
 <20200528163856.GB107313@msg.df7cb.de>
 <20200528164404.GA6680@tamriel.snowman.net>
 <20200528165205.GC107313@msg.df7cb.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA"
Content-Disposition: inline
In-Reply-To: <20200528165205.GC107313@msg.df7cb.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


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

Greetings,

* Christoph Berg (myon@debian.org) wrote:
> Re: Stephen Frost
> > > Why do I have to decide *in pg_hba.conf* which hash algorithm is used?
> >=20
> > Where else would you decide..?
>=20
> Connections could just use whatever hash is used for the username in
> pg_authid. There's no reason to expose that detail in pg_hba.conf.

ok, so, that's currently what the 'md5' setting does.  The scram-sha-256
setting is intended to be used to force scram-sha-256 connections and to
not allow md5 or other ones.

> > > Why can't that just be "password"?
> >=20
> > What would that mean?
>=20
> The above.

So..  it'd be an alias for md5, basically.  I don't think that's
actually a great answer overall as people will want an option that
disallows non-scram password hash usage.

> > > Getting this mess fixed would be good for security because then people
> > > will likely start using scram.
> >=20
> > That's certainly true, though I hope we can convince people to use SCRAM
> > even given the modest effort required.
>=20
> It's not modest. Or else this thread wouldn't have 20 mails.

This is about the default, not about convincing an individual person or
organization.

> > The point here though, really, is that *new* installations of PG have
> > very little reason to not use SCRAM.  The question on upgrades is
> > different, but that can be addressed with pg_upgradecluster, I would
> > think, without much trouble.
>=20
> In pg_createcluster, if I move pg_hba.conf and password_encryption to
> scram, and I restore a dump from an older PG major, can people
> continue to connect using their passwords? From what I got above, the
> answer is "no".

That really depends on what exactly is in the dump file.  If the
contents of the dump file include md5 hashes then those roles wouldn't
be able to log in.  If the contents have SCRAM-based hashes, then sure.
Is that a huge issue?  Not in my view- it'd be pretty clear quite
quickly that they couldn't log in, and why, and that'd be easy to fix-
they could manually adjust the pg_hba.conf, if they want to, or update
those passwords to be scram.

> Should I only set password_encryption to scram and keep advertising
> md5 as the sane default for pg_hba.conf?

That would allow the above scenario to work, though I don't feel the
"what if they restore a pg_dumpall to perform an upgrade, and don't use
pg_upgradecluster" to be a terribly interesting case to stress about
making everything work perfectly- they'll very likely already be having
to adjust their pg_hba.conf for other reasons, as well as their
postgresql.conf for various settings.  Restoring a pg_dumpall dump
(which is what you're talking about here really, of course) has never
done anything for config files.

Thanks,

Stephen

--neYutvxvOLaeuPCA
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCgAGBQJez/BeAAoJEO1sijiDR2RVd6cQAIvfCP4YdV7GM2E8UpiOa9hV
sGS8CUpFBst8rWOxtrYjByRHLWENyU69PrNIVO06E/2CwjHMpzPCtbM3mCXtErBX
MQggw30+UeAHSDCeWA+rXvdh0/ncygoy0IhQ4NOCcQ+/GdhdaHTckaBlJ22qHJGV
nlFcViPGcCu2V9/cDev3hvFaxmto5J2hrZN2GHmKgLEAZ3Suz5fVMHn6Gn1NjKB9
NnHy0bbG3ZpxXEuFTkSSQP9W/f5yjtBjlWw49rAq0GMSe1msCmOj9MvgVrUKHzkp
Grl+epjimdE0QRKJjMAcotZNNIyII5ExvdBxAT+ps7H0GUkqOWMyWO0uR9nluVOT
Xd9Rh3R899uLasPBE75P9GbjLFfQcExH8jalB4p1tShDpXWvJSZDpXN0UptUN3Vr
BTNWssAgWLyH+FEjAGtpBdag7e1soCn6n33hXdadjCYMvSz4oBXf0Binr9bQpMae
HS0dtyiR1a4CVUe4z3c3C/V94akRl9nKdcBIJmZ4DPOVTBOKAYO6CzodILrSAr9i
piYvJIzbReiRIPoDFkVfqza53lrUZdPf8tpiKChKwsvy829M7g1MkybdXSV4oRVx
j3LiRdpwF3qLGexpmuXVQ5zQk1oj/99ayYEMaFui3MgT6sXOfnSJ02vWDba/p4Za
IUUOB7fQAPeMjmcpR0dn
=uBnp
-----END PGP SIGNATURE-----

--neYutvxvOLaeuPCA--