public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jonathan S. Katz <[email protected]>
To: Stephen Frost <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: samay sharma <[email protected]>
Cc: [email protected]
Subject: Re: Proposal: Support custom authentication methods using hooks
Date: Tue, 1 Mar 2022 16:17:28 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 3/1/22 8:31 AM, Stephen Frost wrote:
> Greetings,
> 
> * Michael Paquier ([email protected]) wrote:
>> On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote:
>>> Keeping it around will just push out the point at which everyone will
>>> finally be done with it, as there's really only two groups: those who
>>> have already moved to scram, and those who won't move until they want to
>>> upgrade to a release that doesn't have md5.
>>
>> FWIW, I am not sure if we are at this point yet.  An extra reason to
>> remove it would be that it is a support burden, but I don't have seen
>> in recent memory any problems related to it that required any deep
>> changes in the way to use it, and its code paths are independent.
> 
> Ongoing reports that there's a known vulnerability aren't great to have
> to deal with.  We can at least point people to scram but that's not
> great.
> 
>> The last time I played with this area is the recent error handling
>> improvement with cryptohashes but MD5 has actually helped here in
>> detecting the problem as a patched OpenSSL would complain if trying to
>> use MD5 as hash function when FIPS is enabled.
> 
> Having to continue to deal with md5 as an algorithm when it's known to
> be notably less secure and so much so that organizations essentially ban
> its use for exactly what we're using it for, in fact, another reason to
> remove it, not a reason to keep it.  Better code coverage testing of
> error paths is the answer to making sure that our error handling behaves
> properly.

So, I generally agree with Stephen and his arguments for dropping the 
md5 mechanism.

If you're moving to a newer version of PostgreSQL, you likely have to 
update your connection drivers anyway (rebuilt against new libpq, 
supporting any changes in the protocol, etc). I would prefer more data 
to support that argument, but this is generally what you need to do.

However, we may need to step towards it. We took one step last release 
with defaulting to SCRAM. Perhaps this release we add a warning for 
anything using md5 auth that "this will be removed in a future release." 
(or specifically v16). We should also indicate in the docs that md5 is 
deprecated and will be removed.

We also need to think about upgrading: what happens if I try to upgrade 
and I still have user passwords stored in a md5 hash? What if all my 
password-based users have a md5 hash, does pg_upgrade fail?

As much as I want md5 gone, I think v16 is the earliest we can do it, 
but we can lay the groundwork for it now.

Thanks,

Jonathan


Attachments:

  [application/pgp-signature] OpenPGP_signature (840B, ../[email protected]/2-OpenPGP_signature)
  download

view thread (23+ messages)  latest in thread

reply

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Proposal: Support custom authentication methods using hooks
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox