Re: Credcheck- credcheck.max_auth_failure

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 <hjp-pgsql(at)hjp(dot)at>於 2024年12月14日 週六，上午4:24寫道：

> On 2024-12-11 13:43:38 -0500, Ron Johnson wrote:
> > On Wed, Dec 11, 2024 at 12:57 PM Greg Sabino Mullane <htamfids(at)gmail(dot)com
> >
> > wrote:
> >
> > On Wed, Dec 11, 2024 at 5:46 AM 張宸瑋 <kenny020307(at)gmail(dot)com> wrote:
> >
> > 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.
> >
> >
> > 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(at)hjp(dot)at | -- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
>