Re: PATCH: warn about, and deprecate, clear text passwords

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