Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t5XDp-006mBi-4Y for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Oct 2024 21:24:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t5XDm-009ymM-3P for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Oct 2024 21:24:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t5XDl-009ymE-QQ for pgsql-hackers@lists.postgresql.org; Mon, 28 Oct 2024 21:24:18 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t5XDj-003TuJ-Mj for pgsql-hackers@postgresql.org; Mon, 28 Oct 2024 21:24:17 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 49SLO2GU038127; Mon, 28 Oct 2024 17:24:02 -0400 From: Tom Lane To: Jim Nasby cc: Greg Sabino Mullane , Nathan Bossart , Andrew Dunstan , Heikki Linnakangas , pgsql-hackers Subject: Re: sunsetting md5 password support In-reply-to: References: <7e9e3d30-f7f4-460f-a626-6cfad419d6cd@iki.fi> <76396e05-0724-4b17-9194-2875df40feb8@dunslane.net> <2735114.1728599306@sss.pgh.pa.us> <17ccc98a-108a-415d-a38c-f12b7baab90d@dunslane.net> Comments: In-reply-to Jim Nasby message dated "Mon, 28 Oct 2024 16:10:29 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38125.1730150642.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Oct 2024 17:24:02 -0400 Message-ID: <38126.1730150642@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jim Nasby writes: > Patch itself looks good, but it does leave me wondering if cleartext sho= uld also be deprecated? Not much point unless we also deprecate all of the other auth methods that require cleartext password transmission, which from a quick scan include PAM, BSD, LDAP, and RADIUS. Seems unlikely to fly. In any case, I don't think this is about password security per se. It's more about deprecating a method that might look like it's secure but isn't. In the case of the cleartext-password methods, it's obvious that you'd better use SSL or GSS encryption if you want your password hidden from network tapping. I don't recall how in-your-face we are about that point, but certainly the docs need to be up front about it, and probably make the point explicitly with respect to the four methods listed above. regards, tom lane