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

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

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