Re: NIST SP 800-63B and Passwords

["Manjak, Martin" <mmanjak () ALBANY EDU>]

This has been a very worthwhile discussion. However, one benefit of requiring complexity that’s been overlooked is that 
it has forced users to create separate passwords for their campus accounts vs. reusing passwords created under lax 
composition rules imposed by other service providers. That distinction, more than any other, has saved students and 
staff from having their accounts exposed when Yahoo, Linkedin, etc, suffered their major breaches.

Marty Manjak
CISO
University at Albany

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Steven 
Alexander
Sent: Tuesday, August 1, 2017 3:47 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] NIST SP 800-63B and Passwords

“Since the purpose (or one of the purposes) of password expiration is to force the passwords to be changed sooner than 
they can be broken by an offline brute force attack”

In most cases, password expiration fails to protect against this and makes passwords more vulnerable to offline attack. 
 A guess rate of 10 to 20 billion guesses per second is pretty reasonable with current hardware so most short passwords 
(8 characters or less) and many longer ones (up to ~14 characters) can be cracked within a day.  Plus, research shows 
that users pick weaker passwords and use common patterns (e.g. “Summer2017”) in response to expiration requirements.  
You’re better off without password expiration even if your passwords are unsalted.  If you’re using a strong password 
hash, expiration is absolutely unnecessary to prevent offline cracking.

Steven Alexander
Director of IT Security
Kern Community College District


From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of David 
Curry
Sent: Tuesday, August 1, 2017 6:06 AM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] NIST SP 800-63B and Passwords

But, you can't take those requirements out of context.

For example, this sentence:

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

does not stand alone; it is part of a larger set of requirements and recommendations. Most importantly, before this 
statement, the same section (5.1.1) says:

"When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets 
against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY 
include, but is not limited to:

     *   Passwords obtained from previous breach corpuses.
     *   Dictionary words.
     *   Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
     *   Context-specific words, such as the name of the service, the username, and derivatives thereof.
If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a 
different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value."

So unless your password-changing solution is doing all that, you might want to rethink turning off your other 
complexity requirements, since, as Grampp and Morris so aptly put it more than 30 years ago, "left to their own ways, 
some people will still use cute doggie names as passwords."

As for the second sentence:

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

Here too, there are a whole bunch of other requirements in there about how passwords should be salted and hashed to 
make offline attacks against passwords difficult. A quick Google search suggests that neither Windows' (Active 
Directory's) nor Linux's password hashing schemes meet these requirements (although I didn't look very hard, so I may 
well be wrong about that).

Since the purpose (or one of the purposes) of password expiration is to force the passwords to be changed sooner than 
they can be broken by an offline brute force attack, you may want to weigh the strength of your password system's 
salting/hashing scheme against NIST's requirements before turning off your password expiration rules altogether.

Oh, and +1 to everything Gary said in his reply, as well. :-)



--

DAVID A. CURRY, CISSP
DIRECTOR OF INFORMATION SECURITY
INFORMATION TECHNOLOGY

71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003
+1 212 229-5300 x4728 • david.curry () newschool edu<mailto:david.curry () newschool edu>

[The New School]

On Mon, Jul 31, 2017 at 8:11 PM, Miguel Hernandez <miguel.hernandez () domail maricopa edu<mailto:miguel.hernandez () 
domail maricopa edu>> wrote:

Colleagues,


A question about the latest version of NIST SP 800-63B (Authentication and Lifecycle Management) 
(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.

[eSig Logo]

Miguel Hernandez IV, Ph.D. CISSP, CISA
Associate Vice Chancellor ITS
Chief Information Security Officer
2411 West 14th Street, Tempe AZ 85281
email | miguel.hernandez () domail maricopa edu<mailto:miguel.hernandez () domail maricopa edu>
website | https://www.maricopa.edu<https://www.maricopa.edu/>

Follow me on Twitter<https://twitter.com/mh4phd>.

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.