Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tkPfa-003gY7-UN for pgsql-bugs@arkaria.postgresql.org; Tue, 18 Feb 2025 15:37:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tkPfZ-00BU1o-8S for pgsql-bugs@arkaria.postgresql.org; Tue, 18 Feb 2025 15:37:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tkPfY-00BU1g-VM for pgsql-bugs@lists.postgresql.org; Tue, 18 Feb 2025 15:37:56 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tkPfW-001XbR-2J for pgsql-bugs@lists.postgresql.org; Tue, 18 Feb 2025 15:37:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 51IFbqhh1241095; Tue, 18 Feb 2025 10:37:52 -0500 From: Tom Lane To: Indrajeeth Deshmukh cc: David Rowley , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs In-reply-to: References: <18817-771682052a364bfe@postgresql.org> Comments: In-reply-to Indrajeeth Deshmukh message dated "Tue, 18 Feb 2025 18:22:36 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1241093.1739893072.1@sss.pgh.pa.us> Date: Tue, 18 Feb 2025 10:37:52 -0500 Message-ID: <1241094.1739893072@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Indrajeeth Deshmukh 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