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 1sLKmZ-00EPwh-Dv for pgsql-general@arkaria.postgresql.org; Sun, 23 Jun 2024 10:49: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 1sLKmX-009BZj-Kx for pgsql-general@arkaria.postgresql.org; Sun, 23 Jun 2024 10:49:13 +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 1sLKmX-009BZa-9Z for pgsql-general@lists.postgresql.org; Sun, 23 Jun 2024 10:49:13 +0000 Received: from smtp.burggraben.net ([2a01:4f8:140:510a::3]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sLKmQ-0037zY-FP for pgsql-general@lists.postgresql.org; Sun, 23 Jun 2024 10:49:12 +0000 Received: from elch.exwg.net (elch.exwg.net [IPv6:2001:470:7120:1:127b:44ff:fe4f:148d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "elch.exwg.net", Issuer "R3" (verified OK)) by smtp.burggraben.net (Postfix) with ESMTPS id 28658C01100; Sun, 23 Jun 2024 12:49:05 +0200 (CEST) Received: by elch.exwg.net (Postfix, from userid 1000) id D6F713AB2B; Sun, 23 Jun 2024 12:49:04 +0200 (CEST) Date: Sun, 23 Jun 2024 12:49:04 +0200 From: Christoph Moench-Tegeder To: Martin Goodson Cc: Tom Lane , pgsql-general@lists.postgresql.org Subject: Re: Password complexity/history - credcheck? Message-ID: References: <79692c1a-190c-413e-9442-a14a45c1069d@googlemail.com> <834558.1719102188@sss.pgh.pa.us> <43826fbd-2d26-467b-afcf-7fde609f8da3@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <43826fbd-2d26-467b-afcf-7fde609f8da3@googlemail.com> User-Agent: Mutt/2.2.13 (2024-03-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ## Martin Goodson (kaemaril@googlemail.com): > I believe that our security team is getting most of this from our > auditors, who seem convinced that minimal complexity, password history > etc are the way to go despite the fact that, as you say, server-side > password checks can't really be implemented when the database receives > a hash rather than a clear text password and password minimal > complexity etc is not perhaps considered the gold standard it once > was. The current state of the art is documented (as in, "official", for arguing with auditors) at https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 My advice would be to not use secrets stored in the database - that is, do not use scram-sha-256 - but use an external authentication system, like Kerberos (might be AD) or LDAP (might also be AD) and have that managed by the security team: that way all these compliance topics which they brought up also become their problem :) and a lot of the processes of recovering and disabling accounts and changing passords move into a central location, which is most often a good thing[tm]. Or maybe move to client certificates, but if you're managing more than a few personal accounts rotating certificates might become a hassle (depending on your user base). Regards, Christoph -- Spare Space