On Wed, Oct 9, 2024 at 1:44 PM Jonathan S. Katz <jk...@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
