=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> When I have logging set to 'ddl', and create a user, I can see their
> password in plain text in the logs:
> postgres=# create user example with password 'secretpassword';
> CREATE ROLE
> 2018-10-15 10:09:03.513 EDT postgres 127.0.0.1 postgres psql LOG:
> statement: create user example with password 'secretpassword';
Yup. There are ways to hash the password on the client side before
sending, if you want to defend against that.
> This may not technically be a 'bug'. However, it should not be
> out-of-the-box behavior. The password itself should be obfuscated from the
> logs by default.
This complaint has been made before, and rejected before, and I do not
foresee the policy changing. Obfuscating the logs is impractical on
both performance and system-structural grounds. And if we tried, it
would be unreliable --- for instance, if you misspelled any of the
keywords in this example command, would you still expect the hypothetical
log obfuscator to figure out that it should get rid of 'secretpassword'?
Moreover, in most database situations where you'd really care about
password secrecy, there is a lot of *other* data going through the
system that you'd not want exposed to prying eyes, either. Credit
card numbers, personally-identifiable medical data, yadda yadda are
all likely to be there in logs of INSERT/UPDATE/SELECT commands.
The short answer here is that you need to limit access to the log
files just as much as the rest of the database data.
regards, tom lane