On 21/02/2025 23:33, Greg Sabino Mullane wrote:
There have been a few complaints lately about the fact that we
cavalierly allow clear text passwords to be sent when doing CREATE USER
or ALTER USER. These, of course, can end up in many places, such as
pg_stat_activity, pg_stat_statements, .psql_history, and the server
logs. It is a genuinely valid complaint, and for security purposes,
there is little recourse other than telling users "don't do that". The
canonical recommendation is to use psql's awesome \password feature.
Second best is to use your application/driver of choice, which hopefully
has support for not sending passwords in the clear.
Please find attached a patch to implement a new GUC called
cleartext_passwords_action as an attempt to solve these problems. It is
an enum and accepts one of three values:
1. "warn" (the new default)
This issues a warning if a clear text password is used, but allows the
change to proceed. The hint can change to recommend \password if the
current application_name is 'psql'. By keeping this as a warning, we let
people know this is a bad idea, and give people time to modify
their applications.
Examples:
ALTER USER alice PASSWORD 'mynewpass';
WARNING: using a clear text password
DETAIL: Sending a password using plain text is deprecated and may be
removed in a future release of PostgreSQL.
HINT: Use a client that can change the password without sending it in
clear text
ALTER USER eve PASSWORD 'anothernewpass';
WARNING: using a clear text password
DETAIL: Sending a password using plain text is deprecated and may be
removed in a future release of PostgreSQL.
HINT: If using psql, you can set the password with \password
2. "allow"
This does nothing, and thus emulates the historical behavior.
3. "disallow"
This prevents the use of plain old text completely, by throwing an error
if a password set or change is attempted. So people who want to prevent
clear text can do so right away, and at some point we can make this the
default (and people can always change to hint or allow if desired)
Bike shedding welcome. I realize the irony that 'disallow' means valid
attempts will now show up in the database logs that otherwise would not,
but I'm not sure how to work around that (or if we should).
I'm obviously +1 on this patch since I sent kinda the same patch two
weeks ago
(https://www.postgresql.org/message-id/8f17493f-0886-406d-8573-0fadcb998b1d%40dalibo.co).
The only major difference is that your patch can completely disable
plain text passwords. More options, that sounds better to me.
--
Guillaume Lelarge
Consultant
https://dalibo.com
