Date: Thu, 7 Mar 2024 01:34:39 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: coelho.viniciusdf@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18379: LDAP bind password exposed
Message-ID: <Zelf/6znl4ZbFeR9@tamriel.snowman.net>
References: <18379-385d04dcaa62d6fd@postgresql.org>
 <139544.1709739622@sss.pgh.pa.us>
 <Zei4mtDc4s0LN6bR@tamriel.snowman.net>
 <295987.1709754748@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="r5LZoHaBHpt8V26k"
Content-Disposition: inline
In-Reply-To: <295987.1709754748@sss.pgh.pa.us>
User-Agent: Mutt/2.1.4 (2021-12-11)
Archived-At: 
 <https://www.postgresql.org/message-id/Zelf/6znl4ZbFeR9%40tamriel.snowman.net>
Precedence: bulk


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

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > While I agree that users should take steps to secure their log files,
> > I'd argue that it's best practice to avoid dumping sensitive data into
> > log files, which it seems like it would be in this case.  I'm not
> > suggesting that this is bug-worthy or that we should go to excessive
> > lengths to try and prevent every such case, but if someone showed up
> > with a reasonable patch to replace the sensitive information in a pg_hba
> > line with ****, I would be on the side of supporting that.
>=20
> I dunno, I think it would mostly serve to set false expectations.

I appreciate that concern.  I don't think it will though.

> We've repeatedly rejected requests to scrub the log of passwords
> found in CREATE/ALTER USER commands, for example.  I think some
> of the same issues that led to that conclusion would apply here,
> notably that a syntax error could lead to failing to recognize
> at all that some substring is a password.  (A visibly erroneous
> pg_hba line would not get quoted in the specific context the OP
> complains of, but I'm pretty sure we'd print it while logging
> the configuration reload failure.)

While this may not be popular, I'd be in support of doing away with
support for cleartext passwords being accepted through CREATE/ALTER USER
commands, therefore eliminating this issue entirely.  As discussed on
this very thread, passing passwords in the clear from the client to the
server, in any context, goes against best practices, which is why PG's
ldap auth method is discouraged as it does exactly that.

Doing this would, ideally at least, result in a lot more use of libpq's
PQchangePassword() and \password in psql, which would further reduce the
chances of a syntax error ending up dumping sensitive data into the log
(the server's SCRAM password authenticator would still be considered
sensitive and worthy of hiding, imv, but I wouldn't push as hard on that
as it's clearly less of a risk than the user's cleartext password).

Sure, mistakes could still happen and we couldn't do anything about it
(a user might *try* to pass in a cleartext password via ALTER USER *and*
have a syntax mistake), but now we're really looking at low probability
issues.

Thanks!

Stephen

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

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

iQIzBAABCgAdFiEEwf6gbxKhD863zrx/7WyKOINHZFUFAmXpX/0ACgkQ7WyKOINH
ZFUjlQ/+JNnt62MNa2xq7+2w8YLJCt7XMejZNZTEmFkbmmYiLkKe8OfsxEkBZ2Z1
4IPhcpwGYlWbc0vcBPzX/9J4aUjTKs7ypKIL5E/sL1mCY+BYrHU5J5tOQUB/CPrq
JE9k36ImQBp+jjw9E4jatV+x3ml8nK9oHpPusN1er/f0bvKdsonWNLuuko5y3YSz
TJYrY6+ObRwZ4pJs5R7MxPywoA5XQ6OcgLDgHmUtemgJlcmlZ6dKMoGtiCZH2qyD
96k8PgfrVX7S+i2+Q0BNdjIdD5WEOLJQ7Ocs5NXy16s+pZEUiXjrCXx/w1BC1l9b
5Vvkb5vcb3c8I8cy0BMXqXNqDnsHpLEZFM510BxrVNNof1tnPY59aRqOHxP2uboL
YRakpDXl9KiuwRS2Bj8+hzGuOZcd9J2NJOpiy8Kb5CwUSt3av2zukfDiSfnvEsuI
Pu260tbEPR2hhpEwe0aQVSBcdFl7FNiDR7tVDRIQ7tU8BuNjvLD/gQ4mxkq8O7Sv
TMdFqckSyJFAZLYEaSX44TjRZpK8rJ6HlNOGC7dJjpxxJx5IGQGW4XJewOM0u6CE
44HEtXTHUUftac6xmwwyDQiihrMoLX25CGN7nJMMoXVcwTGKKbVQ5eHEicKZIUgS
jVtRdEV6Vqp+/BQAQ02kjc9JjkqlgDuswza93xkNlDevOKGTrgw=
=dIgh
-----END PGP SIGNATURE-----

--r5LZoHaBHpt8V26k--