SecurityInnovation/TMContentReview — Issue #100: How to Test for Account Lockout Bugs
Author: SergeTruth
Created: 2011-11-07 22:43:55+00:00
State: open

... an attacker launches the account lockout attack simply by trying to log [in to]

Should be one word.

"To fully avoid this vulnerability, the application must apply an account lockout policy that doesn’t block a legitimate client from using the application, or, in other words, no account lockout policy, which is insecure because it opens the application to brute-force/dictionary attacks."
When you use in other words you are clarifying something not pointing out the opposite

I think the important thing here is that the userIds' are not enumerable (consecutive employee ids) such that a DOS attack could be executed on the application by locking out all users.

This issue is debateable as the problem outlined is the result of having a lock out policy.