Categories Topics
Account Lockout

Accounts used to access systems, applications or devices should be locked out after a defined number of unsuccessful login attempts to help reduce the risk of unauthorized access to sensitive systems and data. Accounts should be locked out until reset by an approved service. If no lockout threshold is set, intruders can attempt to guess the password many times to include malicious tools at their disposal (e.g. dictionary attacks). The account lockout control should complement other access control measures to include longer password lengths, password complexity, password history, and monitoring to name a few.

Account lockout thresholds should be set to a small number, especially for critical applications (to include internet facing web applications). The most common standard is to set the maximum to 3 such that an account will lockout after the fourth unsuccessful login attempt.

Locked out accounts should only be reset through an "approved service". Examples of approved services include help desk to unlock account and/or reset password or self-service password recovery tools. With the high cost of help desks, such self-service tools have become more popular since they enable end-users to reset their own password after answering a series of "secret" questions (e.g., first pets name, place of birth, etc.).

Other mechanisms to control account lockouts include Active Directory, where accounts can be automatically unlocked after a set time period (e.g. 30 minutes). Organizations may also need to evaluate availability requirements and impact caused by locked accounts used for automation (such as running system or application services).  In those cases, it may be plausible to raise the account lockout threshold to a higher number. In either scenario, there should be very good compensating controls are in place to monitor password attempts/lockouts to help reduce the potential risk of unauthorized access.

Topic Category
Access Control
News Articles
Cisco, Interpol team up to share cybercriminal threat datawww.zdnet.com11/21/2017