[cabf_netsec] Brute Force Attacks and Account Lockout - NCSSR 2.g.ii and 2.k.

[Ben Wilson]

All,

The purpose of this email is just to start a broad and healthy discussion
about password length for online accounts. Subsections 2.g.ii. and 2.k.,
quoted below, specify 8-character passwords and account lockout after 5
attempts. I don't believe that password generation and complexity are
stated in NCSSRs.  Then there is the account lockout subsection itself,
subsection 2.k.

I have done some research (as mentioned on our last call), but I haven't
yet found an authoritative source (for cross-referencing in the NCSSRs)
that states a simple password rule that we can incorporate by reference. I
don't think NIST 800-63B Appendix A -
https://pages.nist.gov/800-63-3/sp800-63b.html#appA
is specific enough ("The minimum password length that should be required
depends to a large extent on the threat model being addressed."), unless we
want to latch on to stick with 8 characters based on section 5.1.1. of
800-63b -
https://pages.nist.gov/800-63-3/sp800-63b.html#-511-memorized-secrets -
"Memorized secrets SHALL be at least 8 characters in length if chosen by
the subscriber."

For the sake of discussion, I'll assert:

that a 12-character, pseudo-randomly generated password is strong enough
for online use;

that if so, then an account lockout feature is an unnecessary defense
against online attacks;

that pseudo-random password generation could be required (or recommended as
a "SHOULD"); and

that Section 2.k. could be rewritten/repurposed.


Assuming passage of the current draft of the "Zones" ballot, subsection
2.g.ii of the NCSSRs would then state (or we could include additional
changes, based on these discussions, since the ballot is still in draft
form):

ii.               For authentications from outside the boundary of the CA’s
network, require Multi-Factor Authentication and that any passwords have at
least eight (8) characters and are not one of the user's previous four
(4) passwords;
and implement account lockout for failed access attempts in accordance with
subsection k;

(How necessary for security is the requirement that it be "Not one of the
user's previous four passwords"?)

Subsection 2.k. of the NCSSRs states:


k. Lockout account access to Certificate Systems after no more than five
(5) failed access attempts, provided that this security measure:

i.                Is supported by the Certificate System,

ii.                Cannot be leveraged for a denial of service attack, and

iii.                Does not weaken the security of this authentication
control;


Note that if the lockout mechanism can be leveraged for a denial of service
attack (2.k.ii), then the CA is excused from implementing this security
measure.


However, a CAPTCHA-type mechanism could be employed against DoS and/or the
MFA required by 2.g.ii is a sufficient preventative measure against any
DoS-type attack.


Subsection 2.k. might still find use protecting Certificate Systems inside
the CA's network.  It could also be eliminated where passwords alone are
not the authentication mechanism (e.g. assuming MFA is in use).   Account
lockout could also be turned into a recommendation - a "SHOULD".  However,
it is noted that account lockout is a good threat mitigation against online
guessing. https://pages.nist.gov/800-63-3/sp800-63b.html#throttle


So, hypothetically, subsection 2.k. could be re-written, repurposed, or
deleted.


Also, subsection 2.g.ii. could be amended to read:  "For authentications
from outside the boundary of the CA’s network, require Multi-Factor
Authentication and that any passwords have at least twelve (12) eight
(8) characters.
and are not one of the user's previous four (4) passwords; and implement
account lockout for failed access attempts in accordance with subsection k;
Such passwords MUST/SHOULD be pseudo-randomly generated from a set of at
least 94 characters."


Or maybe 8-character passwords are fine when MFA is required/implemented
and the lockout cross-reference can just be eliminated from 2.g.ii.


Like I say above, this is just to get us talking.


Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20200515/22767591/attachment.html>