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 1tN8PG-008nWF-5X for pgsql-general@arkaria.postgresql.org; Mon, 16 Dec 2024 10:32:54 +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 1tN8PB-005HUa-KZ for pgsql-general@arkaria.postgresql.org; Mon, 16 Dec 2024 10:32:50 +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 1tN8PB-005HSN-1g for pgsql-general@lists.postgresql.org; Mon, 16 Dec 2024 10:32:50 +0000 Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tN8P9-0036II-9b for pgsql-general@lists.postgresql.org; Mon, 16 Dec 2024 10:32:49 +0000 Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-3a9d465da82so1313415ab.1 for ; Mon, 16 Dec 2024 02:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734345166; x=1734949966; darn=lists.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=/OJkWkzFxxuHSXueWHNjB9SHUe1+2R2LrkMDr7u2aC8=; b=KFzH2oQZ12nhMCNK3eMUlpp+btam3WME5Ab4WGiB7XZOuOZhoOjr00AahmOSdeEyry rlsEf5TFHch/F9qdRdfQcTdWBwqK0+o0gY8zTQFeZzUTVKafeM9IM3qLd4kGZBJFGcsb 0GmAvPKWUHXsWm8S0bpachLnuHVzXHWzzDJr+rZkde2tdfMWXOfazHPPM2ItIae+EKZ0 CGpVV8XndNp1tsjUU+DDzi0qgJ16ersE4c1wnuceHyniyiaUsm/602mju/ZtejYwnIdv mk0uzEE04JWjRY9SoFSpBWWlDVck7w4ZNwGKoAAABoy8y9+bpolR/InVPBGVxg2fuAQn SXrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734345166; x=1734949966; 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=/OJkWkzFxxuHSXueWHNjB9SHUe1+2R2LrkMDr7u2aC8=; b=QNWEcJX9DXdEdZexHTCoWfThHPmC6vy8ZGqzCQxuiB9o7lpmfMqmn+Q9nNtIj85bG2 6oWmB2fVi7kfytjnarKs28xerGHxzDzky6YKfA4Cd2wH1LoGcQQxeF/BNkQrDrVHzxzf 8uXquG6iuI388ekrFW/mR54X8wIPQcFwOoCHhhNb84KoMVvcyEVLdkH4mui1RbSIoCvY cDhEk7WuShdkX03gb948MtOA3oiavo9Ek+NsLqAGxMi+R/2kf7VSL7xIgA0xicBhj52w ts8kX9u3Oaws9sP/dG3DbG1JGhf9AYePwZpGQct9mD6GfkUjbpVG4PdaKN4n3sfZRAdl WzbA== X-Gm-Message-State: AOJu0YzD9ZfYc4kuN8LT8a8AaavBcVK5rlG3nqWaDwzevji81+VVaCdE AMrnY4vNd7KcAWmQKtsTiZq35ajLf0CHcUoDmi3DaJfqqZ/aCHjOF+kkO/LuQY6SRlNeJe+JInR aZzUNdvcgjpcwcF8nPjGHEgcjfDcavw== X-Gm-Gg: ASbGncsTDV3xPRnKlUzAwvitsr64Qcex4GSIFOfIXTdSHcyL2PMu2jDA9G2K3Kk8drz u/9qnnxX/Y7+he2Tgc9/lV2/OI4dLW9EgWoCpbUrElXF74scXOYq3+N/nvJjaSTyfReoGSw== X-Google-Smtp-Source: AGHT+IEmqsZeSHHj6TcKhcER4t1D6LTpFx+GsWPdAC/O6Aa0zCT4P1e+mqJCvP97tzzurUYZTOuOHSMfmThy434m1bs= X-Received: by 2002:a05:6e02:156d:b0:3a7:de79:4bae with SMTP id e9e14a558f8ab-3aff4614639mr24967285ab.6.1734345165794; Mon, 16 Dec 2024 02:32:45 -0800 (PST) MIME-Version: 1.0 References: <20241213202348.jtchbb2lezbx2re6@hjp.at> In-Reply-To: <20241213202348.jtchbb2lezbx2re6@hjp.at> From: =?UTF-8?B?5by15a6455GL?= Date: Mon, 16 Dec 2024 18:32:34 +0800 Message-ID: Subject: Re: Credcheck- credcheck.max_auth_failure To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000008674de062960b380" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008674de062960b380 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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 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 > > > 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.c= onf > file > > to limit users from entering incorrect passwords more than thre= e > times, > > after which their account will be locked. > > > > > > Won't that allow absolutely anyone to lock out anyone else, includi= ng > > 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 t= o > 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!" > --0000000000008674de062960b380 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have both regular accounts and system accounts. For regular ac= counts, 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. 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 pro= blems. To prevent this, we would like to exclude system accounts from being= affected by the credcheck.max_auth_failure parameter.

=
Peter J. Holzer <hjp= -pgsql@hjp.at>=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
<= /div>
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&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;
--0000000000008674de062960b380--