From: Jonathan S. Katz <jkatz@postgresql.org>
To: Nathan Bossart <nathandbossart@gmail.com>
To: pgsql-hackers@postgresql.org
Subject: Re: sunsetting md5 password support
Date: Wed, 9 Oct 2024 16:44:43 -0400
Message-ID: <a19ed13d-f69e-4644-9c96-1e18aa7d6550@postgresql.org> (raw)
In-Reply-To: <ZwbfpJJol7lDWajL@nathan>
References: <ZwbfpJJol7lDWajL@nathan>
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_driversAttachments:
[application/pgp-signature] OpenPGP_signature.asc (839B, ../a19ed13d-f69e-4644-9c96-1e18aa7d6550@postgresql.org/2-OpenPGP_signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jkatz@postgresql.org, nathandbossart@gmail.com
Subject: Re: sunsetting md5 password support
In-Reply-To: <a19ed13d-f69e-4644-9c96-1e18aa7d6550@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox