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 1tNBuq-009ByV-Ok for pgsql-general@arkaria.postgresql.org; Mon, 16 Dec 2024 14:17: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 1tNBun-007I14-G7 for pgsql-general@arkaria.postgresql.org; Mon, 16 Dec 2024 14:17:42 +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 1tNBun-007I0u-2V for pgsql-general@lists.postgresql.org; Mon, 16 Dec 2024 14:17:42 +0000 Received: from mail-oo1-xc30.google.com ([2607:f8b0:4864:20::c30]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tNBul-0039hZ-Cy for pgsql-general@postgresql.org; Mon, 16 Dec 2024 14:17:41 +0000 Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-5f2e13cb359so1066932eaf.3 for ; Mon, 16 Dec 2024 06:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734358657; x=1734963457; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=AjF8FcNd95ondqp5Ag+gYHtc3w9Uq+eR1OdoNIRyOgU=; b=dRfZXnQBVaE4qgNzfssymYhIVrjAkasSDHiHQ9+LaSGrK9+f8DW76lP7aroB/eYeSO dJZrqMxae+F1ZqxjfTNRkz2Up0eiIcJM3YMUzRzXh0Yf8VeyArcV4JEXjpwDpte8DmUL Mlt2iPPHy3B7vJ51lw2ifOxkK90Om1PXT9uQ8MZPpDZU3ghq79ExIl2wYMG7fhuYN8LM Ghsc/kLn3mN00Q3hVe3p6sENR3Bv40MPNdDKaPO8SVGcyQz9275eXgzugEdwr7JbObAG 9TkbqqDM6SH3mlBBjxZFiELGYDtQq6MIVTUIrb9ZhZ/UvjlYXaiRYrMsy9XQfPibxvdh KCvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734358657; x=1734963457; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AjF8FcNd95ondqp5Ag+gYHtc3w9Uq+eR1OdoNIRyOgU=; b=w0mQPOQs25+JwHE3obN7q1//k3J+c15Bx4Orm218n8bPIL3xxf89l4PfTivVhyTFBl xtD3TMTYbYxO+bV1ANZX6Z2i1KPMa/qg67zJLXpTRAYeURbPJSSaX+rxA56c7eTS/VaL ZCkmdfSlfB75w8FAcxDHfjWTsyGBDVCFvnNs6cvQrc6Aom4swViiGq6bCzCV5nOir0NZ 67qF3v4Hjn7C2owOboUP34rhcCS6lFY8B4t1U8LPYJWpf1mJGHBJHRpYO1OsV/w98hdr rqjDuAEoJ8PLQhFQmHXzOglt1TRuaiAwq61SyGluB5YTLtJsH+KXXkAwIS9bFHTbpN+o ZgAg== X-Gm-Message-State: AOJu0YxP4BMZ/xg2kAr9VWdsfV0XumH3Q8ynFUqd/r+RU6i+ARIiBClR G0GQUuW/dlIUORhwChSfuB+xc/h4MuRWi/k3jeuCQs3reCitznu9Ss4pZ4u94ApfdbHHC8+TT9e /sxuNEeXZDNLlQSp7Tbgw6avLdte71w== X-Gm-Gg: ASbGnct0cFgiPvo+Lt8C9gcb4NAlxOXL+Kb2MlpVIRsqnzng5Er13axL/4RkM33rRLo N4OvERu4e5H10Ca6eC0iY/E16trwPIT47R//WQtk= X-Google-Smtp-Source: AGHT+IGPahBLys1HpnkALIGeqlVyo4QLlYUfy1psifFN1tbJApvhxLgdFWS0cfd6kd00IatO1nbWl9bMDd6wg3JjEBQ= X-Received: by 2002:a05:6870:558d:b0:29e:4578:5f74 with SMTP id 586e51a60fabf-2a3ac537869mr5381510fac.4.1734358657143; Mon, 16 Dec 2024 06:17:37 -0800 (PST) MIME-Version: 1.0 References: <20241213202348.jtchbb2lezbx2re6@hjp.at> In-Reply-To: From: Ron Johnson Date: Mon, 16 Dec 2024 09:17:25 -0500 Message-ID: Subject: Re: Credcheck- credcheck.max_auth_failure To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000ac1b6a062963d7e7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ac1b6a062963d7e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Local (socket-based) connections are typically peer-authenticated (meaning that authentication is handled by Linux pam). Thus, if someone enters too many wrong passwords for a superuser account, you *should* still be able to locally connect to PG. Better test it, though. On Mon, Dec 16, 2024 at 5:32=E2=80=AFAM =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 > multiple failed login attempts. However, for system accounts, due to > information security regulations, password complexity is also required. T= he > 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 prevent this, we would like to exclude system accounts from > being affected by the credcheck.max_auth_failure parameter. > > > Peter J. Holzer =E6=96=BC 2024=E5=B9=B412=E6=9C=8814=E6= =97=A5 =E9=80=B1=E5=85=AD=EF=BC=8C=E4=B8=8A=E5=8D=884:24=E5=AF=AB=E9=81=93= =EF=BC=9A > >> On 2024-12-11 13:43:38 -0500, Ron Johnson wrote: >> > On Wed, Dec 11, 2024 at 12:57=E2=80=AFPM Greg Sabino Mullane < >> htamfids@gmail.com> >> > wrote: >> > >> > On Wed, Dec 11, 2024 at 5:46=E2=80=AFAM =E5=BC=B5=E5=AE=B8=E7=91= =8B wrote: >> > >> > In the use of the Credcheck suite, the parameter >> > "credcheck.max_auth_failure =3D '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. >> > >> > >> > Won't that allow absolutely anyone to lock out anyone else, >> including >> > admins/superusers? Sounds like a bad idea to me. >> > >> > >> > Isn't this a pretty common password setting? >> >> Yes, but that doesn't mean it's a good idea. >> >> Actually, let me tease that apart a bit. >> >> It is very common for the setting to exist (probably just about any OS >> and many applications, too), but much less common for it to be turned on= . >> >> There are good reasons for that. >> >> Limiting the number of failed attempts makes a lot of sense for debit >> cards: The PINs are short enough that a person could bruteforce all >> combinations and that typos are uncommon. So multiple failed attempts >> probably mean that the card was stolen. There is also no way to DOS >> somebody, since you need the card before you can enter the PIN. >> >> It may have made a bit of sense in the 1980s, when most people had short >> and easily guessable passwords and hosts were typically only accessible >> from directly connected terminals and not from the internet. >> >> But it really doesn't make much sense now: Passwords should be so long >> that brute-forcing them via login attempts is completely futile. Either >> the attacker knows the password (then the limit doesn't help), or they >> won't guess it in a million attempts (so the limit doesn't help either). >> OTOH, the limit gives an attacker a very simple way to deny the service = to >> the legitimate used: Just enter a bogus password three times and boom - >> account locked. (That threat can be mitigated by applying the limit per >> IP address - but the attacker may have a botnet with a million nodes, >> making the limit ineffective.) >> >> hp >> >> -- >> _ | Peter J. Holzer | Story must make more sense than reality. >> |_|_) | | >> | | | hjp@hjp.at | -- Charles Stross, "Creative writing >> __/ | http://www.hjp.at/ | challenge!" >> > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000ac1b6a062963d7e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Local (socket-based) connections are typically peer-a= uthenticated (meaning that authentication is handled by Linux pam).

Thus, if someone enters too many wrong passwords for a su= peruser account, you should=C2=A0still be able to locally connect to= PG.

Better test it, though.

On Mon, Dec 16, 2024 at 5:32=E2=80=AFAM =E5=BC=B5=E5=AE=B8=E7=91=8B <<= a href=3D"mailto:kenny020307@gmail.com">kenny020307@gmail.com> wrote= :
We h= ave both regular accounts and system accounts. For regular accounts, we sti= ll require password complexity and the lockout functionality after multiple= failed login attempts. However, for system accounts, due to information se= curity regulations, password complexity is also required. The issue is that= system accounts are used for system integration, and if the account gets l= ocked, it may affect system services, which could lead to problems. To prev= ent this, we would like to exclude system accounts from being affected by t= he credcheck.max_auth_failure parameter.


Peter J. Holzer <= hjp-pgsql@hjp.at&= gt;=E6=96=BC 2024=E5=B9=B412=E6=9C=8814=E6=97=A5 =E9=80=B1=E5=85=AD=EF=BC= =8C=E4=B8=8A=E5=8D=884:24=E5=AF=AB=E9=81=93=EF=BC=9A
On 2024-12-11 13:43:38 -0500, Ron John= son wrote:
> On Wed, Dec 11, 2024 at 12:57=E2=80=AFPM Greg Sabino Mullane <htamfids@gmail.com&g= t;
> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Dec 11, 2024 at 5:46=E2=80=AFAM =E5=BC=B5= =E5=AE=B8=E7=91=8B <kenny020307@gmail.com> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the use of the Credcheck suite, th= e parameter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"credcheck.max_auth_failure =3D = '3'" is set in the postgresql.conf file
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to limit users from entering incorrec= t passwords more than three times,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0after which their account will be loc= ked.
>
>
>=C2=A0 =C2=A0 =C2=A0Won't that allow absolutely anyone to lock out = anyone else, including
>=C2=A0 =C2=A0 =C2=A0admins/superusers? Sounds like a bad idea to me. >
>
> Isn't this a pretty common password setting?

Yes, but that doesn't mean it's a good idea.

Actually, let me tease that apart a bit.

It is very common for the setting to exist (probably just about any OS
and many applications, too), but much less common for it to be turned on.
There are good reasons for that.

Limiting the number of failed attempts makes a lot of sense for debit
cards: The PINs are short enough that a person could bruteforce all
combinations and that typos are uncommon. So multiple failed attempts
probably mean that the card was stolen. There is also no way to DOS
somebody, since you need the card before you can enter the PIN.

It may have made a bit of sense in the 1980s, when most people had short and easily guessable passwords and hosts were typically only accessible
from directly connected terminals and not from the internet.

But it really doesn't make much sense now: Passwords should be so long<= br> that brute-forcing them via login attempts is completely futile. Either
the attacker knows the password (then the limit doesn't help), or they<= br> won't guess it in a million attempts (so the limit doesn't help eit= her).
OTOH, the limit gives an attacker a very simple way to deny the service to<= br> the legitimate used: Just enter a bogus password three times and boom -
account locked. (That threat can be mitigated by applying the limit per
IP address - but the attacker may have a botnet with a million nodes,
making the limit ineffective.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 hp

--
=C2=A0 =C2=A0_=C2=A0 | Peter J. Holzer=C2=A0 =C2=A0 | Story must make more = sense than reality.
|_|_) |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
| |=C2=A0 =C2=A0| hjp@hjp.a= t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 -- Charles Stross, &q= uot;Creative writing
__/=C2=A0 =C2=A0| http://www.hjp.at/ |=C2=A0 =C2=A0 =C2=A0 =C2=A0challenge!&q= uot;


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000ac1b6a062963d7e7--