Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Indrajeeth Deshmukh <bkindrajeeth(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs
Date: 2025-02-18 15:37:52
Message-ID: 1241094.1739893072@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Indrajeeth Deshmukh <bkindrajeeth(at)gmail(dot)com> writes:
> Thanks for sharing the details. It looks like a valid issue and has not
> been resolved yet. Currently, the solution is keeping the file remains
> secure, but when it comes to SIEM monitoring, it will be a major concern.
> Any thoughts on this?

The real bottom-line answer to that is that passwords are just the
tip of the iceberg. The server log is likely to contain other
critical information depending on your application; consider credit
card numbers, HIPAA-protected medical details, etc. The server
has no way at all to know which fields might be sensitive in that
way. Even if we had some notion of which fields to hide, in cases
like statements with syntax errors, we couldn't reliably identify
which parts of a query string are sensitive.

The only solution is to treat the server log files with the same
amount of care as you give to the database files themselves.
Or send them to /dev/null, but that's unlikely to be very workable
in practice.

Independently of that, best practice is to never send cleartext
passwords to the server in the first place. psql has support
for setting a password without that, and I think libpq does too.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2025-02-18 16:38:53 BUG #18818: Access to postgres repo
Previous Message Greg Sabino Mullane 2025-02-18 14:38:38 Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs