Re: Credcheck- credcheck.max_auth_failure

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: 張宸瑋 <kenny020307(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Credcheck- credcheck.max_auth_failure
Date: 2024-12-16 13:09:45
Message-ID: CAKAnmmJQmpN14wCpOsM9mCEXagwWWONyA+BYszMQJ5ExxOEfXA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.
>

Again, what is the threat model here? Most people have their password in a
.pgpass file or similar, so it seems this only adds complexity and
annoyance without any real benefit.

However, for system accounts, due to information security regulations,
> password complexity is also required.
>

Yes, this makes sense.

> 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.
>

I think we all understand that, but the extension as it exists now cannot
do that. And the obvious and easiest solution is to stop using the denial
of service feature, which I am hoping is NOT mandated by security
regulations.

Cheers,
Greg

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2024-12-16 14:13:16 Re: Credcheck- credcheck.max_auth_failure
Previous Message Peter J. Holzer 2024-12-16 11:34:31 Re: Credcheck- credcheck.max_auth_failure