Re: NIST SP 800-63B and Passwords

["Flynn, Gary - flynngn" <flynngn () JMU EDU>]

I think those recommendations should be considered in the greater context of the document.

 

Other recommendations associated with memorized secrets:

·         Minimum of 8 characters which may be all numeric.

·         Must be compared against list that contains values known to be commonly used

·         Shall implement a rate-limiting mechanism that effectively limits the number of failed authentication 
attempts (5.2.2: to no more than 100 - yay!)

·         Shall store memorized secrets in a form that is resistant to offline attacks.

 

More importantly, there are three levels of authentication strength -  AAL1 - AAL3. Memorized secrets by themselves are 
suitable ONLY for AAL1. So how trustworthy is AAL1 and when should it (and memorized secrets alone) be used?

 

"AAL1 provides some assurance that the claimant controls an authenticator".

"AAL2 provides high confidence…"

"AAL3 provides very high confidence…"

 

"Any PII or other personal information - whether self-asserted or validated - requires multi-factor authentication" and 
"agencies SHALL select a minimum of AAL2 when self-asserted PII or other personal information is made available online".

 

Additionally, for AAL1:

"The CSP SHALL employ appropriately-tailored security controls from the low baseline of security controls" and "CSP 
SHALL ensure that the minimum assurance-related controls for a low-impact systems, or equivalent, are satisfied".

 

So while the document allows complexity checking and password changes to be eliminated, it also limits password-only 
protection to low-impact systems with no PII. Otherwise, multifactor authentication is required. AAL1's "some 
assurance" is not appropriate for protecting other people's PII data or critical services including ERP, email, file 
storage, etc. If you have a "critical systems list", they're automatically disqualified as being defined as "low-impact 
systems" and therefore must use two factor authentication according to this document….as they should be, particularly 
if exposed to the Internet. "Hello, cloud providers…."

 

Gary Flynn

JMU IT Security

James Madison University

 

 

 

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Miguel 
Hernandez
Sent: Monday, July 31, 2017 8:12 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] NIST SP 800-63B and Passwords

 

Colleagues,

 

A question about the latest version of NIST SP 800-63B (Authentication and Lifecycle Management) ( 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__doi.org_10.6028_NIST.SP.800-2D63b&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=BHm0mJ51u5rGXwLzi_1Sog&m=uHgR4UFHbfVP7PPR9aRzdJT-PyNQmCQ-EsOgNqqZv-w&s=o9pQui2d67-6Fj3iVd3PP5EHFIvDeINl2RwTGrUTQtE&e=>
 https://doi.org/10.6028/NIST.SP.800-63b).  

 

Since its release in June, not a week has gone by without a handful of IT folks stopping by and asking when we are 
going to (1) disable all password complexity requirements and (2) stop requiring periodic password changes.  

 

As I’ve reviewed the NIST publication I note the two recommendations quoted below which has fueled the above questions:

 

“Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or 
prohibiting consecutively repeated characters) for memorized secrets.”

 

“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).“

 

So my question is: Do any of you have a sense of urgency to disable your password complexity checks and disable 
password expiration?  Is this something you plan to implement over time?  Will you create some relaxed version of your 
current password rules (for example, maybe require at least upper and lower case, and extend password expiration to 1 
year).  Or will you just continue with business as usual and make no changes.  

 

The use of the word “SHOULD” is of course non-mandatory language and is only a recommendation.  There are some though 
who think these recommendations are actually requirements and must be implemented immediately.  I’d just like to get an 
idea of what my fellow higher-ed institutions are doing.  

 


  <https://www.maricopa.edu/sites/default/files/Maricopa_Sig.png> 

Miguel Hernandez IV, Ph.D. CISSP, CISA

Associate Vice Chancellor ITS

Chief Information Security Officer

2411 West 14th Street, Tempe AZ 85281

email |  <mailto:miguel.hernandez () domail maricopa edu> miguel.hernandez () domail maricopa edu

website |  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.maricopa.edu_&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=BHm0mJ51u5rGXwLzi_1Sog&m=uHgR4UFHbfVP7PPR9aRzdJT-PyNQmCQ-EsOgNqqZv-w&s=LbV3xmPyT-Fd4rLr31xgSFBSgRdXo8C0T3Ol_X_3DUs&e=>
 https://www.maricopa.edu

Follow me on Twitter 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_mh4phd&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=BHm0mJ51u5rGXwLzi_1Sog&m=uHgR4UFHbfVP7PPR9aRzdJT-PyNQmCQ-EsOgNqqZv-w&s=rR6ip_KEsZat5xDIIfHEj7vydICGkSJ0clMMQxT6_t8&e=>
 .

 

This message contains information which may be confidential and/or privileged. If you are not the intended recipient of 
this message, please notify the sender, delete and do not use or disseminate this information.

Attachment: smime.p7s
Description: