On 22/02/2025 09:07, Guillaume Lelarge wrote:
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.
It applies cleanly, compiles without errors or even warnings.
I did some tests, and I only found one small issue:
set password_encryption to 'md5';
create user u4 password 'md5u1';
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
WARNING: setting an MD5-encrypted password
DETAIL: MD5 password support is deprecated and will be removed in a
future release of PostgreSQL.
HINT: Refer to the PostgreSQL documentation for details about migrating
to another password type.
CREATE ROLE
It complains that I'm using a plain text password and a MD5-encrypted
password. Can't be both. (Probably not an issue with this patch, but
rather an issue with the commit that implemented MD5-password warnings.)
If I use a real md5 password, it only complains about MD5 encrypted
password:
create user u5 password 'md58026a39c502750413402a90d9d8bae3c';
WARNING: setting an MD5-encrypted password
DETAIL: MD5 password support is deprecated and will be removed in a
future release of PostgreSQL.
HINT: Refer to the PostgreSQL documentation for details about migrating
to another password type.
CREATE ROLE
Other tests were successful.
Thanks Greg!
--
Guillaume Lelarge
Consultant
https://dalibo.com
