Re: sunsetting md5 password support

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: sunsetting md5 password support
Date: 2024-10-10 12:40:18
Message-ID: 76396e05-0724-4b17-9194-2875df40feb8@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2024-10-09 We 7:11 PM, Heikki Linnakangas wrote:
> On 09/10/2024 22:55, Nathan Bossart wrote:
>> In this message, I propose a multi-year, incremental approach to
>> remove MD5
>> password support from Postgres.
>
> +1
>
>>   2.  In v19, allow upgrading with MD5 passwords and allow
>> authenticating
>>       with them, but disallow creating new ones (i.e., restrict/remove
>>       password_encryption and don't allow setting pre-hashed MD5
>> passwords).
>
> This is a bit weird state. What exactly is "upgrading"? I guess you
> mean pg_upgrade, but lots of people use pg_dump & restore or logical
> replication or something else entirely for upgrading. That's
> indistinguishable from setting a pre-hashed MD5 password.
>
> I think it's bad if you cannot pg_dump & restore your database.

Hmm, yeah. It would be easy enough to prevent MD5 passwords in things
like CREATE ROLE / ALTER ROLE, but harder to check for MD5 if there are
direct updates to pg_authid. Maybe we need to teach pg_dumpall a way to
do that as a workaround?

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-10-10 12:43:32 Re: On disable_cost
Previous Message Christoph Moench-Tegeder 2024-10-10 12:27:04 Re: sunsetting md5 password support