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 1sLB0l-00DnyK-EJ for pgsql-general@arkaria.postgresql.org; Sun, 23 Jun 2024 00:23:15 +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 1sLB0i-000pKz-V3 for pgsql-general@arkaria.postgresql.org; Sun, 23 Jun 2024 00:23:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sLB0i-000pKq-Em for pgsql-general@lists.postgresql.org; Sun, 23 Jun 2024 00:23:12 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sLB0g-002dsF-4Q for pgsql-general@lists.postgresql.org; Sun, 23 Jun 2024 00:23:11 +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 45N0N8Jd834559; Sat, 22 Jun 2024 20:23:08 -0400 From: Tom Lane To: Martin Goodson cc: pgsql-general@lists.postgresql.org Subject: Re: Password complexity/history - credcheck? In-reply-to: <79692c1a-190c-413e-9442-a14a45c1069d@googlemail.com> References: <79692c1a-190c-413e-9442-a14a45c1069d@googlemail.com> Comments: In-reply-to Martin Goodson message dated "Sun, 23 Jun 2024 00:28:21 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <834557.1719102188.1@sss.pgh.pa.us> Date: Sat, 22 Jun 2024 20:23:08 -0400 Message-ID: <834558.1719102188@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Martin Goodson writes: > Recently our security team have wanted to apply password complexity > checks akin to Oracle's profile mechanism to PostgreSQL, checking that a > password hasn't been used in x months etc, has minimum length, x special > characters and x numeric characters, mixed case etc. Don't suppose it would help to push back on whether your security team knows what they're doing. The really key reason why server-side password checks are not as bright an idea as they sound is that they cannot be implemented without forcing the client to transmit the password in cleartext. It's widely considered best practice if the server *never* sees the user's cleartext password, because then it can't leak, either from sniffing the connection or scraping the postmaster log. I believe that practices such as forcing a password change every X amount of time are not viewed as favorably as they once were, either. (The argument is that that discourages users from putting any serious thought into choosing an uncrackable password, and might well encourage them to write down their current and last few passwords somewhere.) Anyway, considerations like these are why there's not features of this sort in community PG. You can use an extension that applies some checks, but there's no good way around the "needs cleartext password" problem for that. regards, tom lane