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