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 張宸瑋 <kenny020...@gmail.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-pg...@hjp.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 < >> htamf...@gmail.com> >> > wrote: >> > >> > On Wed, Dec 11, 2024 at 5:46 AM 張宸瑋 <kenny020...@gmail.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. >> |_|_) | | >> | | | h...@hjp.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!
