Date: Tue, 28 Nov 2023 10:16:41 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>,
	Michael Paquier <michael.paquier@gmail.com>,
	PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Changing references of password encryption to hashing
Message-ID: <ZWYEWeHaUrFmW5nx@tamriel.snowman.net>
References: <CAB7nPqR82_57C8O1+z-bUChhHpdjMec_omLfKwYdjAFjjcrBWg@mail.gmail.com>
 <ZV149Fd2JG_OF7CM@momjian.us>
 <ZWX/Y5napgIxs6VA@tamriel.snowman.net>
 <CA+Tgmoa44Q+rajT2FC2S7R3-hfh0xXTEa+qLzdYD0Gh9DPoX3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="jK/RENHqnKjsc/MJ"
Content-Disposition: inline
In-Reply-To: <CA+Tgmoa44Q+rajT2FC2S7R3-hfh0xXTEa+qLzdYD0Gh9DPoX3Q@mail.gmail.com>
User-Agent: Mutt/2.1.4 (2021-12-11)
Archived-At: <https://www.postgresql.org/message-id/ZWYEWeHaUrFmW5nx%40tamriel.snowman.net>
Precedence: bulk


--jK/RENHqnKjsc/MJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Nov 28, 2023 at 9:55=E2=80=AFAM Stephen Frost <sfrost@snowman.net=
> wrote:
> > I do think we should use the correct terminology in our documentation
> > and would support your working on improving things in this area.
>=20
> +1.
>=20
> > I do wonder if perhaps we would be better off by having someone spend
> > time on removing terribly insecure authentication methods like md5 and
> > ldap though ...
>=20
> Wait, what's insecure about LDAP?

We pass a completely cleartext password to the server from the client.
Yes, we might encrypt it on the way with TLS, but even SSH realized how
terrible that is long, long ago and strongly discourages it these days.

The problem with ldap as an auth method is that a single compromised PG
server in an AD/ldap environment can collect up those username+password
credentials and gain access to those users *domain* level access.  The
CFO logging into a PG server with LDAP auth is giving up their complete
access credentials to the entire AD domain.  That's terrible.

> I think we should eventually remove MD5, but I think there's no rush.

I disagree- it's a known pass-the-hash vulnerability and frankly every
release we do with it still existing is deserving of an immediate CVE
(I've been asked off-list why we don't do this, in fact).

> People who care about security will have already switched, and people
> who don't care about security are not required to start caring.

I wish it were this simple.  It's just not though.

> Eventually the maintenance burden will become large enough that it
> makes sense to phase it out for that reason, but I haven't seen any
> evidence that we're anywhere close to that point.

This seems to invite the idea that what people who care about this need
to do is make it painful for us to continue to keep it around, which I
really don't think is best for anyone.  We know it's bad, we know it is
broken, we need to remove it, not pretend like it's not broken or not
bad.

Thanks,

Stephen

--jK/RENHqnKjsc/MJ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEwf6gbxKhD863zrx/7WyKOINHZFUFAmVmBFkACgkQ7WyKOINH
ZFW/2BAAu/aD8WlQ1UUIXm7U2sTEStHqkExkK3YFFakNzyaVEJWzoqWM3E/x27j1
l4xz6D8p3srDupkJ/kP/A48CJdN2UDS1VDszliquFTIHlnvCF7wcdNSvltmqI0sE
HhMstOMAytP3sqAqv7seWzLQ9JGejODqEd8ls8g8QQ3qS0G4oHoyOQ29m+LGNzvE
2D+EZGGpdtf2/dPAKlJtGcKinc1V/kLo92uoCoIp87vWetNyqoUy5cmchLYl64+y
7avbhPuLD6xscxamNDCbneVjbR/ROGnpKuB84G7jfS48XrpFbsJPJhOpQFyyBYon
61SCXxE6F5LTmbMLj40DdwiEeuBefC6R5lhCepDzBBopH/0ojZbXtXReNiwlH0xQ
iGeKRnq2sEFREuEv+IPF05Xr0f65awfbf/u9IQ+vIsc30fBawkeP8/Pm/UNthWqk
7QGmapFkiJYhx/9wi50jH4AxZwh76jQMJfAApS0zJeAsUzE6d+t6e4ocLvH5KMOT
sw/hhyg4uWohphSPKRk6TaT8Vwec7Uww269Yt/6tWlnLZlrwyXR8Bhr9NR811wFu
duZVaaqWmKKE9MGOmovDTnH7R6PXiBzUu05vyDv5btyZFZknBwhuRnlXRwjedRSX
27wDHl2psrjuuSyS/3gorORmnOcjTqjjNOvnskIpphhUVUGyLBU=
=yogH
-----END PGP SIGNATURE-----

--jK/RENHqnKjsc/MJ--