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 1tN9N6-008tgm-Pe for pgsql-general@arkaria.postgresql.org; Mon, 16 Dec 2024 11:34:44 +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 1tN9N3-005pgA-8L for pgsql-general@arkaria.postgresql.org; Mon, 16 Dec 2024 11:34:42 +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 1tN9N2-005pg2-PP for pgsql-general@lists.postgresql.org; Mon, 16 Dec 2024 11:34:41 +0000 Received: from mail.hjp.at ([212.17.106.138] helo=rorschach.hjp.at) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tN9Mw-0036qK-De for pgsql-general@lists.postgresql.org; Mon, 16 Dec 2024 11:34:40 +0000 Received: by rorschach.hjp.at (Postfix, from userid 1000) id 16A0F64E2C; Mon, 16 Dec 2024 12:34:31 +0100 (CET) Date: Mon, 16 Dec 2024 12:34:31 +0100 From: "Peter J. Holzer" To: pgsql-general@lists.postgresql.org Subject: Re: Credcheck- credcheck.max_auth_failure Message-ID: <20241216113431.v5rnxexalfj6eorv@hjp.at> Mail-Followup-To: pgsql-general@lists.postgresql.org References: <20241213202348.jtchbb2lezbx2re6@hjp.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="j6sutcw7j4z2vjbl" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --j6sutcw7j4z2vjbl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024-12-16 18:32:34 +0800, =E5=BC=B5=E5=AE=B8=E7=91=8B wrote: > We have both regular accounts and system accounts. For regular accounts, = we > still require password complexity and the lockout functionality after mul= tiple > failed login attempts. However, for system accounts, due to information > security regulations, password complexity is also required. The issue is = that > system accounts are used for system integration, and if the account gets > locked, it may affect system services, which could lead to problems. To p= revent > this, we would like to exclude system accounts from being affected by the > credcheck.max_auth_failure parameter. Just in case it wasn't clear: My recommendation is to NOT use the credcheck.max_auth_failure parameter for ANY account. It just causes problems and doesn't really help. If you can't trust your users to chooses sufficiently strong passwords, use a second factor. Or maybe replace passwords with some other method (public keys, FIDO, ...) altogether (in fact, I'd do that for system accounts). hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --j6sutcw7j4z2vjbl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmdgEEEACgkQ8g5IURL+ KF3rwQ//TOr58+1RjKo486MsmFR/ESt6ivJAMaMlpAPct/q7cCu0FHPxBiaceLPU VpAo0kB3V+ECev1u1lXCRgMxDsKvPJRiRl/A0FVtCL7W6gFrY9cTlLD8L9DLdT99 kzBMDgobAVhmTODO5bHdSa+gTE6ODi3nOcyr8hEQROiPkINP4Rl26NE5KcLIviTV 0mlft7Yx6gDqSfyFxwYudU/rW7IkVe7xQdR25RRN3hGmfawUMxGm4nK7if6Ny3iJ s4nkVvEzCG35C1+FoNEDuODnWTEuzWH1RsFXo01nbbp0H6dCVKSuQWiWwb44INGg hMZdDINEBK88JmQ231X+dZN3Ip9iPXOaeh7Z6lTKtZadG/xm/NRkEuKyBjnWWuz8 MMyaxnHSaMSviKELnwI1k6xR06tM2R6ers90ctz4y2qXiBQiCl9nokj1KExTTdQZ nEMG4/W7xpo6Pcsr4XnFgWK6tU1i4DRGo9kjn3FZuCWkIHaFHQTtPzhdQNH9R/00 Ww+VxK9pHeOtDG+rIcVw9Dv21OvAFeNngOLiOBhTZHU1CLlCUduJY7wpb0QhuLXl sj1AQHAHrWS1t53M5bqosEZJswrn78/QhBLOSFLIg0rS60hAtl4rIGsjiiRc0WGr WAmqek7i+G/EDiyhReIp/e1gtfZOZnwJ5j9138NjuJBvI4bxya8= =zwdh -----END PGP SIGNATURE----- --j6sutcw7j4z2vjbl--