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