split from 2.2.1 - disallow account lockout

[elarlang]

Spin-off from #1763 (comment)

As current 2.2.1 requires work, and should have a clear anti-automation goal, it makes sense to separate the lockout part from this.

First question is - do we need this requirement? What NIST says about it? How it can fire back?

In practice - I have seen "enough times" solutions that via some web application authentication form you can lock out an entire organization or company user base with incorrect credentials.

Idea proposal from @tghosth

Verify that malicious users cannot lock out legitimate users and admins through excessive incorrect login attempts?

This serves to goal to explain the idea, but should be written as positive requirement.

[tghosth]

I feel that we satisfy this enough by not requiring lockout and I don't really want a separate requirement but I am open to suggestions.

[elarlang]

What NIST says about it?

For my surprise, NIST kind of agrees to "no lockout" direction (although not requiring it).

3.2.2 Rate Limiting (Throttling)

Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out due to rate limiting. These include:

• Requiring the claimant to complete a bot-detection and mitigation challenge before attempting authentication
• Requiring the claimant to wait after a failed attempt for a period of time that increases as the subscriber account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour)
• Accepting only authentication requests from IP addresses from which the subscriber has been successfully authenticated before
• Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within or outside typical norms (e.g., the use of the claimant’s IP address, geolocation, timing of request patterns, or browser metadata)

[tghosth]

So do you still want a separate requirement here? if so, what is your proposed wording @elarlang ?