...
Calculating Password Entropy
Appendix A includes a length lengthy discussion on password complexity and related issues. For purposes of this discussion, min-entropy is defined as "a measure of the difficulty of guessing the easiest single password to guess in the population", and compliance with this requirement can be achieved using dictionary checks or long passwords, and as such further consideration of min-entropy is out of scope for this discussion.
...
The simplest conceptual model for limiting authentications is to count the number of failed authentication events and to expire a credential that reaches the limit. Other options include establishing policies that make it mathematically impossible to reach such a limit, usually based on x failures within y minutes triggering a z minute lockout, with password passwords expiring every n days. Password Entropy Calculators can can help determine such policies. Example compliant policies could beinclude
Maximum Failures | Failed Attempts Before Lockout | Lockout Duration | Password Expiration |
|---|---|---|---|
1048576 (Bronze) | 15 | ~10 minutes | Annual |
65536 (Silver) | 15 | ~2 hours | Annual |
...
A simple counter is also a simple policy. For sufficiently large permitted numbers of failed authentication events, the likelihood of an individual reaching the maximum threshold under normal circumstances is exceedingly low, minimizing user impact. Where Where the threshold is approach approached (let alone reached), it is likely due to reasons that are desirable to have detected, eg an attack in progress or misconfigured email client.
Lockout policies as described above are typically enforced at the credential store. In a heterogeneous environment a heterogeneous environment with multiple credential stores, such as AD, LDAP, and RADIUS, coordinating these policies across the credential stores is exceedingly difficult. Instead, the policies must may need to be "split". In the previous example, perhaps 5 failed attempts trigger a lockout at each credential store (since one must assume a concurrent attack against all three credential stores). It is easier to centralize a simple counter across multiple credential stores. A centralized tracking facility also simplifies user support.
...
- The approach is subject to denial of service attack. While true, a lockout is also subject to denial of service attacks, and arguably more quickly.
- The approach is a single point of failure. This depends on the actual implementation , -- it is possible to invest sufficiently to make each part highly available. Furthermore, if the central counter is offline, IAQs could simply not be asserted for the duration.
- There may be a delay in the processing of records and the subsequent credential invalidation. Given that the InCommon IAPs require credential revocation within 72 hours of notification of compromise (§4.2.4.2), it seems reasonable that a delay of up to several minutes (if not longer) is permissible acceptable in processing an invalidation once a threshold has been reached.
...