Re: Credcheck- credcheck.max_auth_failure

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 AM 張宸瑋 <kenny020307(at)gmail(dot)com> 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. 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!"
>>
>

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!