* Greg Stark ( wrote:
> Locked accounts are a terrible terrible idea. All they do is hand attackers
> an easy DOS vulnerability. They're pure security theatre if your
> authentication isn't vulnerable to brute force attacks and an unreliable
> band-aid if they are.

For starters, our authentication *is* vulnerable to brute force attacks
(as is any password-based system, and I doubt we're going to completely
drop support for them regardless of what else we do here), and second
the account lock-out capability is still required in NIST 800-53 rev4 and
is covered by AC-7.

AC-7 does address the DOS risk and allows organizations to unlock the
account after an organization-specified delay.

I've been able to address that in the past by using Kerberos for PG
instead and implementing the lock-out and other requirements in this
area that PG doesn't support that way, but that isn't available in all
situations which leads to far worse solutions having to be used to meet
these requirements (sorry, but hacking up a PAM-based approach which
uses cracklib and pam_deny is *really* ugly).

> Having dealt with mechanisms for locking accounts in other database they're
> much more complicated than they appear. You need to deal with different
> requirements for different users, have multiple knobs for how it triggers
> and resolves, have tools for auditing the connection attempts to determine
> if they're legitimate and identify where the incorrect attempts are coming
> from, and so on. And all that accomplishes in the best case scenario is
> having lots of busy-work support requests responding to locked accounts
> and in the worst case scenario upgrading minor issues into major service
> outages.

I agree that they're complicated and that auditing is another necessary
component that we don't currently have.  We are woefully behind in these
areas and should certainly look to what others have done and learned
over the past 10 years that these issues have more-or-less been ignored,
but I don't believe we can or should continue to ignore them as it makes
PG unnecessairly more difficult to use in many areas.



Attachment: signature.asc
Description: Digital signature

Reply via email to