Re: sunsetting md5 password support - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: sunsetting md5 password support
Date
Msg-id CAOYmi+nycvB-H-+_wUGaZYrX86QzSNEMw-NzCxZjGbjQNV4xkA@mail.gmail.com
Whole thread Raw
In response to sunsetting md5 password support  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Wed, Oct 9, 2024 at 1:44 PM Jonathan S. Katz <jkatz@postgresql.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



pgsql-hackers by date:

Previous
From: Marcos Pegoraro
Date:
Subject: Re: Mathematical Functions and Operators
Next
From: Heikki Linnakangas
Date:
Subject: Re: sunsetting md5 password support