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 1tLKEh-00E7d6-8S for pgsql-general@arkaria.postgresql.org; Wed, 11 Dec 2024 10:46:31 +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 1tLKEd-00FJEi-VA for pgsql-general@arkaria.postgresql.org; Wed, 11 Dec 2024 10:46:29 +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 1tLKEd-00FJEa-Jj for pgsql-general@lists.postgresql.org; Wed, 11 Dec 2024 10:46:28 +0000 Received: from mail-il1-x12b.google.com ([2607:f8b0:4864:20::12b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tLKEc-002FMj-5w for pgsql-general@lists.postgresql.org; Wed, 11 Dec 2024 10:46:27 +0000 Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-3a8147b8c4cso1838575ab.3 for ; Wed, 11 Dec 2024 02:46:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733913985; x=1734518785; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=YSznWkyilnBGyQSaf8DukjSg2+fMQvLqZ72G7q2+88s=; b=WChypSTrsU7U5vqWuWse6BBPx98FpG2v45cOGKBz+KAnLbLUGmyxjvrt5++QIybmgG zovANToP9bXofKnx7TeeNKXY35EfIQXQvGtAspxYokSeiRJTlx3vJFSRMtklYTMFIo6C Uy2tNCve7/JEmcQ9dNph0JH8358PIJJBfQV1tgGbSKc9MMBEH3ExiSxn3o1mDqpdYKez /I260r5KgVM5P2rB058MBbkM01WPx4Rjt/C0K783Ktrdtb7zxtUoqDXZxIduvjcI6olh rcmJawMy4wcsBmmX9ZpDUYBY7FeINH9sSFjh6ZSXTQtyJVMDc3gjuIRPzrtyOIvLtKAE 00zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733913985; x=1734518785; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=YSznWkyilnBGyQSaf8DukjSg2+fMQvLqZ72G7q2+88s=; b=kPdz6DpcRZQMoCvkPkhJtcXrPdOkuNEpSGrvY9xhc8K6klmYYliv+MZItP48YCeos1 UyD0WQxeHdzkYmEMFPDCX3YoRnRTw2JFwokS74KxJ91btbzmqYTnHbzY5Xnb+D8o9RLL sWK3q3GuKjcIzp2jZPuzxvvQgsRL5yKnXautk8jSmluWMG3wgzF/2JvJZOoDGX2nfP1/ vJf7O1BkredFba+TjB5m4Q6i/dLefOkPNDxEFQvb7zCvjELW2RYT93kNILGguFOZhAJN UM0fpHLc0loghhLVfA5tjGCN8cuvcOyY16DAcUT6BmGjPakPnrZw0QfsdOL9E12Wg1g5 UIvg== X-Gm-Message-State: AOJu0Yx4THv17HL1XzBQ8mRHgxt1ikCjZ9ZRqyhNqQj/JqN0ru1gPeRp 4LIRr7V2abOktPrQEHQXwl10HNwVktM8edfoumDymy6jYu+psUQNro6eRc4LKP0Z1pBX3bVrTar QQm0KuOjZfV+2SaE9vy2gWaOtDmVmROJw X-Gm-Gg: ASbGnctKK0mn7nMrRVFvJQaF6W7xNoJKIWiGOPhmvh36vhpilcRDERWhEM86zCO+254 bf3CisKLLlunaTIjvuQMQ8VTk/Q52It0iNfh3GVI0z5zJ/L9RBOCQ/fSGvmemnpg9PvI= X-Google-Smtp-Source: AGHT+IEdPHNO02i3BAmzmsHP4wWxi42hRLMUetueaPJ1JZ1s9pIiVDiw0M0LWhGuiL3g2wHimuUrrQkuzhT5jHaGEao= X-Received: by 2002:a05:6e02:1a66:b0:3a7:bfc6:be with SMTP id e9e14a558f8ab-3aa098098f3mr6547105ab.5.1733913985039; Wed, 11 Dec 2024 02:46:25 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?5by15a6455GL?= Date: Wed, 11 Dec 2024 18:46:14 +0800 Message-ID: Subject: Credcheck- credcheck.max_auth_failure To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000264a510628fc4fd4" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000264a510628fc4fd4 Content-Type: text/plain; charset="UTF-8" In the use of the Credcheck suite, the parameter "credcheck.max_auth_failure = '3'" is set in the postgresql.conf file to limit users from entering incorrect passwords more than three times, after which their account will be locked. Due to certain requirements, I would like to ask if there is a way or feature to set this parameter differently for a specific user or role, so that it does not apply to them. I considered using "credcheck.whitelist" to exclude certain accounts, but this would cause all other parameters to apply as well, and the account would still require the other password complexity settings. I only wish to exclude the "credcheck.max_auth_failure" parameter. Thank you in advance for your response, and I would appreciate any assistance you can provide! --000000000000264a510628fc4fd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the use of the Credcheck suite, the parameter "credcheck.= max_auth_failure =3D '3'" is set in the postgresql.conf file t= o limit users from entering incorrect passwords more than three times, afte= r which their account will be locked. Due to certain requirements, I would = like to ask if there is a way or feature to set this parameter differently = for a specific user or role, so that it does not apply to them. I considered using "credcheck.whitelist" to exclude certain accou= nts, but this would cause all other parameters to apply as well, and the ac= count would still require the other password complexity settings. I only wi= sh to exclude the "credcheck.max_auth_failure" parameter. Thank you in advance for your response, and I would appreciate any assistan= ce you can provide!
--000000000000264a510628fc4fd4--