Re: sunsetting md5 password support

On Wed, 9 Oct 2024 at 21:55, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> In this message, I propose a multi-year, incremental approach to remove MD5
> password support from Postgres.

+many for the general idea

I think it makes sense to also remove the "password" authentication
option while we're at it (this can currently be used with SCRAM stored
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.

This step sounds like a great way to stress out DBAs who don't read
the release notes carefully. I imagine the following situation: DBA
upgrades to v20. The upgrades succeed, but suddenly half the
applications cannot connect.

It seems much nicer to have the upgrade fail hard in the check phase,
to force all users and thus applications to upgrade their hash to the
new format, i.e. go right from step 2 to step 4.

> Thoughts?

I don't know what a reasonable deprecation cycle is. But I believe all
clients have supported SCRAM auth for quite a long time, so honestly
even disallowing upgrading with md5 passwords in v18/v19 might be
acceptable. I guess my main question is: Who's life do we make easier
by postponing the removal? Is the pain going to be significantly less
for some people by doing a spread out deprecation, instead of just
saying: We stop supporting it next release.

If the pain is going to be the same amount for users anyway, only
postponed a few years, then I don't see much of a reason to wait.

Side-thought: What about the deprecation cycle for md5/password auth
for libpq? I think we'd want to keep it at least 5 years after we
remove it from the server. Probably even longer. But I think we at
least might want to change the default of require_auth to
"!md5,!password" after 5 years.

On Wed, 9 Oct 2024 at 21:55, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> In this message, I propose a multi-year, incremental approach to remove MD5
> password support from Postgres.
>
> The problems with MD5 password hashes in Postgres are well-understood, so I
> won't discuss them in too much detail here. But suffice it to say that MD5
> has been considered to be unsuitable for use as a cryptographic hash
> algorithm for some time [0], and cracking MD5-hashed passwords is trivial
> on modern hardware [1]. Furthermore, MD5 password hashes in Postgres are
> vulnerable to pass-the-hash attacks [2] [3], i.e., knowing the username and
> hashed password is sufficient to authenticate.
>
> The SCRAM-SHA-256 method added in v10 is not subject to these problems and
> AFAIK is generally considered far superior. Since v14, this method has
> been the default for the password_encryption parameter, which determines
> the algorithm to use to store new passwords on disk (unless the password
> has already been hashed by the client, as is recommended).
>
> 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.
>
> 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.
>
> With this plan, the first version with all MD5 password support removed
> would be released in 2028. Considering SCRAM-SHA-256 was first introduced
> in 2017 and has been the default for password_encryption since 2021, users
> will have had several years to migrate.
>
> Thoughts?
>
> [0] https://en.wikipedia.org/wiki/MD5#Security
> [1] https://www.postgresql.org/docs/devel/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE
> [2] https://hashcat.net/misc/postgres-pth/postgres-pth.pdf
> [3] https://www.postgresql.org/docs/devel/auth-password.html
>
> --
> nathan
>
>