NIST has released their guidelines for Digital Identity. (Click this link for document information)

Documents for guidelines for Digital Identity from NIST have been released.  Once you get past the preamble and definitions, they read like expert documents but are missing a great deal of information. At least that is the consensus of various people in the industry including myself.  Albeit that these are the first draft of documents, one would assume that as more people complain or submit revisions, these documents will get revised. 

Like any good policies and procedures, they start with a rough draft and then are modified over the course of their lifetime to include new information as discovered.  No one document can be set in stone in the ever changing Cyber Security realm.

I suggest that you  take a moment to read the "guideline" and see what you think.

Just a couple take aways:

Takeaway #1;

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.

Thoughts:

If you check all PWs or "memorized secrets" based upon existing available compromised lists, dictionary words and or repetitive/sequential (linear) variations, at some point in time you exhaust ALL possible combinations of passwords.  This makes it next to impossible for a user to change their password then.  So what do you offer?

Takeaway #2:

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). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator

Thoughts:

The "should not require memorized secrets (passwords) to be changed periodically"?  Are you serious?  This sounds like a disaster in the making.   Industry standards state "change the passwords frequently". This is usually every 60 to 90 days.  Not all Employees will be changing their PWs on the same days, so randomization of changes does help a little.  Unless the hacker/attacker already owns your AD or password files.

Ok, I am not going to critique the whole set of documents.  Suffice it to say that Published Standards/Guidelines can be counter productive in a secure environment.  This being, when you lay out your Standards/Guidelines, attackers/hackers can use these documents against you to find more ways to attack your organization more.  While Security by obscurity is never a good thing, if you utilize these guidelines as defacto standards, you are asking for trouble. If you use a "guideline" as just that and create your own Standards based in part on these "guidelines", you can actually have the ability to define a more robust policy/Standard for your own organizations.

Remember, a "guideline" is just that.  Throw out the bad advise and incorporate the stronger advise into your internal Standards.

Never look at a guideline as a defacto standard.