Re: sunsetting md5 password support

On Wed, Oct 9, 2024 at 1:44 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
> On 10/9/24 3:55 PM, Nathan Bossart wrote:
> > 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 also think we should start logging warnings as soon as we agree to
deprecate MD5.

> I've mixed feelings on
> this, as this could end up leaking information about what auth methods
> are used.

Leak it to whom? The client and server both know MD5 is being used.

> > 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.

I'd like an accelerated schedule for this too. Your three-step
"complain, restrict, disallow", with strict pg_upgrade failure as part
of step 3, seems right to me.

> (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).

In general I like the three-step method for the server side. The
client side needs to be considered separately, though, like Jelte
pointed out; we have wire compatibility to maintain.

(For the exact example you provided, I think we'd only need a similar
process if the -256 variant turns out to be broken. Otherwise, the
cost of maintaining -256 and -512 together is probably going to be
very close to the cost of maintaining -512 alone, thanks to the past
work generalizing the hashing code. And there may be
security/performance tradeoffs for DBAs to make.)

Thanks,
--Jacob