From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
cc: sreekanta reddy <sreekantareddy18@gmail.com>,
        pgsql-general@lists.postgresql.org
Subject: Re: Permissions for Newly Created User
In-reply-to: <4d672de040dd54b1dd687d20da2eb291f3324fd7.camel@cybertec.at>
References: <CAK5dmvD-63hFPBZ+GnuZEO9Knabpw1wnrWnrHuADjWPFF-Pgvw@mail.gmail.com> <4d672de040dd54b1dd687d20da2eb291f3324fd7.camel@cybertec.at>
Comments: In-reply-to Laurenz Albe <laurenz.albe@cybertec.at>
	message dated "Fri, 18 Oct 2024 16:45:32 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <894609.1729269866.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Oct 2024 12:44:26 -0400
Message-ID: <894610.1729269866@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/894610.1729269866%40sss.pgh.pa.us>
Precedence: bulk

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Fri, 2024-10-18 at 15:41 +0530, sreekanta reddy wrote:
>> When creating or altering a user's password, the log file captures the =
password in plain text format, which could be a potential security risk.
>> However, when using the \password command in psql, the password is logg=
ed in its hashed format (SHA-256), which is a more secure practice.
>> I recommend extending this hashed logging format to all password creati=
on and modification operations.

> You mean to hash it just for logging?

> After you sent it to the server in clear text, so that the DBA could cap=
ture it with an
> event trigger?  Where is the point?  The log file is to be treated as se=
nsitive data.

Yeah.  To enlarge on that: if you are capturing SQL commands in the
log file, they most likely contain all kinds of sensitive data ---
think credit card numbers, bank account numbers, HIPAA-protected
medical details, yadda yadda.  Most of that, the database has no idea
whether it's sensitive, so "please hide sensitive data in the log" is a
non-starter.  You have to guard the postmaster log about as carefully
as you guard the database contents.

			regards, tom lane