The US National Institute of Standards and Technology (NIST) has issued the second public draft of the proposed new version of its Digital Identity Guidelines. It includes updated rules regarding passwords that seem refreshingly sensible. 

Passwords cause headaches for developers and for users. Too weak and they provide no protection at all, too strong and it's all too easy to get personal data locked away in an impenetrable safe. Most of the time I'm happy either to accept the strong password that a new app offers me - perhaps truncating it first, which I admit does weaken it, and then let Chrome be the one that stores and retrieves it as necessary. But have you ever tried typing in one of those strong passwords that contains a mix of uppercase and lowercase letters together with a sprinkling of numbers and special characters on a mobile device? It's a nightmare. And while it used to be possible to stick to desktop apps, more and more mobile apps are being foisted on us for vital tasks such as online banking.

So it is a great relief to discover that the revised guidelines include:

" 5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."

A "verifier" in this context is the entity that verifies an account holder's identity by corroborating the holder's authentication credentials and CSP stands for "credential service provide", that is the trusted entity that assigns or registers authenticators to the account holder. 

Notice the use of "SHALL NOT" for which the NIST uses caps so that we can't miss the instruction. In the past the NIST password guidelines were expressed in terms of "should" and "should not". Now it uses "SHALL/SHALL NOT" for practices that are regarded as mandatory and "SHOULD" for those that, while best practice, have some leeway.

The rule that comes top of the list shows the difference between SHALL and SHOULD:

"1.  Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length."

So, a minimum of 8 characters in a password is mandatory and a minimum of 15 is preferable.

I have to admit to being confused by the next rule:

"2 . Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.

This presumably refers to passphrases, but "maximum" and "of at least" don't go together well - thank goodness it's just a "should". 

The next two rules encourage (SHOULD) accepting the use of all ASCII printing characters and the space character and Unicode characters in passwords.

Another of the changes that is being welcomed as putting an end to the "obsolete requirment" of having to change a password at regular intervals, something that tends to discourange users from adopting high-strength passwords:

"6. Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."

While it's quite a while now since I was asked to provide a "hint" to aid recall of a password, my most used password, to log-on to my computer does show the hint I set for it multiple times a day. It's by far the weakest of any of my passwords anyway. But I would hate to change it after 20, no 30, knocking 40 or is it more years. Does that still happen? Well if it does it's about to be outlawed by the updated rule 7:

"7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant."

I've often reflected on how insecure "mother's maiden name"  and "name of first pet" were as security questions, in particular "city you were born in". These are hardly secrets for most people but used as security questions once you've got past the password stage their use doesn't seem too bad. At least the legitimate user has a chance of remembering them. However the use of prompting users to rely on such knowledge-based authentication in choosing passwords:

"8.Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords."

The final rule eliminates laziness on the part of verifiers - a practice I'd not come across anyway

"9. Verifiers SHALL verify the entire submitted password (i.e., not truncate it)."

Taken as a set these proposed best practices seem fine - and there's still time to have your say, NIST invites people to submit comments on the guidelines to dig-comments@nist.gov by 11:59 pm Eastern Time on October 7.

More Information

SP-800-63B Draft Guidelines

Related Articles

Fluid Passwords - Never The Same Password

GOTCHA - No More Password Hacking

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info