Re: sunsetting md5 password support

On 10/9/24 3:55 PM, Nathan Bossart wrote:
> In this message, I propose a multi-year, incremental approach to remove MD5
> password support from Postgres.

+100; thanks for a concrete proposal. Cutting out the "well-understood" 
problems bit.>
> Given there is a battle-tested alternative to MD5, I propose we take the
> following steps.  I am not wedded to the exact details, but I feel that
> this would be a reasonably conservative path forward.
> 
>   1.  In v18, continue to support MD5 passwords, but place several notes in
>       the documentation and release notes that unambiguously indicate that
>       MD5 password support is deprecated and will be removed in a future
>       release.

+1. Should we also add something in the logs? I've mixed feelings on 
this, as this could end up leaking information about what auth methods 
are used. But - maybe we can pick and choose what we log on, e.g. if 
"md5" is set as an auth method in pg_hba.conf, we complain at 
pg_hba.conf load/reload time that this is being deprecated.

>   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).
> 
>   3.  In v20, allow upgrading with MD5 passwords, but disallow using them
>       for authentication.  Users would only be able to update these
>       passwords to SCRAM-SHA-256 after upgrading

>   4.  In v21, disallow upgrading with MD5 passwords.  At this point, there
>       should be no remaining MD5 password support in Postgres.

I wonder if we can compress this down into the v20 release. With v18 
(2025), we've already had a year of warning (and I think as soon as we 
commit to a plan, we start broadcasting it, so maybe more than a year). 
With v19 (2026), we've started adding the inconveniences, and there's a 
last chance to flip the password. With v20 (2027), we can then block 
upgrades until they're rehashed. That's effectively 3 years from today - 
we can also say it's within the 10 years since SCRAM was introduced, 
which somewhat aligns with other deprecation timelines :)

Given the problems with the md5 method, I think we can be carefully 
aggressive here with the deprecation, particularly given there's overall 
wide support for SCRAM.

(The larger question, which I will pose at least to think on, is how do 
we handle any future password method deprecations, e.g. say 
SCRAM-SHA-512 comes out and we want to remove SCRAM-SHA-256? Not an 
issue today, but we'd likely want to have a similar process in place).

Jonathan

[1] https://wiki.postgresql.org/wiki/List_of_drivers