This document proposes a technical architecture for counting failed password authentication events in order to achieve compliance with InCommon Bronze and Silver Identity Assurance Profiles.
Background
The Version 1.2 of the InCommon Identity Assurance Profiles establish establishes certain standards for the use of credentials. Specifically, for Bronze an attack against an authentication secret shall have less than 1 chance in 1024 of success (§4.2.3.2) and for Silver the attack shall have less than 1 chance in 16,384, as well as at least 10-bits of min-entropy (§4.2.3.3). The profiles refer to NIST Special Publication 800-63-1, Appendix A, for a discussion of Authentication Secret complexity and resistance to online guessing. This strawman will consider the case where simple passwords/passphrases are used to achieve compliance with these requirements -- the use of other technologies such as hardware tokens is out of scope for this discussion.
Calculating Password Entropy
Appendix A includes a lengthy discussion on password complexity and related issues. A mechanism is provided for calculating the password guessing entropy (complexity) of a password, based on its length and other characteristics. For example, an 8 character password requirement with dictionary checks and composition rules has 30 bits of entropy.
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. As such, and as such further consideration of min-entropy is out of scope for this discussion.
Appendix A provides a mechanism for calculating the password guessing entropy (complexity) of a password, based on its length and other characteristics. For example, an 8 character password requirement with dictionary checks and composition rules has 30 bits of entropy.
Applying Entropy To Determine Maximim Unsuccessful Authentication Attempts
...
Continuing with the previous example of an 8 character password, 2 30 / 2 10 = 1048576 1,048,576 failed authentication events would be permitted for Bronze, and 2 30 / 2 14 = 65536 65,536 would be permitted for Silver.
Options For Limiting Unsuccessful Authentications
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 passwords expiring every n days. Password Entropy Calculators can help determine such policies. Example compliant policies include
...
For comparison, NIST SP 800-63-1 1 (Table 6) dramatically simplifies this policy selection by requiring passwords consistent with 14 bits of entropy for LOA 1 and 30 bits of entropy for LOA 2, and mandating no more than 100 failed attempts per 30 day period for either. (Table 6)
Different institutions will take different approaches based upon local requirements. This document does not argue one solution is better or worse than another.
...
Lockout policies as described above are typically enforced at the credential store. In a heterogeneous environment with multiple credential stores, such as AD, LDAP, and RADIUS, coordinating these policies across the credential stores is difficult. Instead, the policies may need to be "split". In the previous example, perhaps 5 failed attempts trigger a lockout at each any one 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.
...
NIST SP 800-63-1 enumerates various problems with maintaining a simple counter (§8.2.3). While some of these are inherent in the highly restrictive policy required (100 failed attempts per 30 day period), some of these are more general and worth can be generalized and are worth some consideration.
- 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 acceptable in processing an invalidation once a threshold has been reached.
...
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
This proposal brings together several components to support multiple integration patterns.
Use of Syslog
This proposal relies on the use of syslog as a mechanism to export failed authentication events from credential stores in (near) real time, as it is widely supported in natively or can be easily supported via add-ons in many flavors of Kerberos, LDAP, and RADIUS, and can be easily supported via add-ons in other environments, including as well as (pending details) Active Directory.
Per-credential store instructions are needed for exporting failed authentication records via syslog.
Some credential store-specific plugins may need to be developed.
...
Optimized modules for failed authentication counting could be developed.
Reference instructions for installation and configuration could would need to be developedwritten.
Database
A relatively simple schema can track failed authentication events as reported to the Accumulator. A basic table would track
...
The final component is the Monitor, responsible for determining when thresholds are reached and taking appropriate action, as well as for managing reset events. The most portable approach may be for the Monitor to periodically poll the database for counts, and then fire off events as appropriate. (It may be possible to leverage database trigger mechanisms to push events to the Monitor, but this is unlikely to be achievable in a cross-platform way.)
...