Enter a new password … no, not that. Or that. Or …

By Mark Gibbs


New guidelines from NIST make password policies sensible

Ronald Reagan famously said "The most terrifying words in the English language are: I'm from the government and I'm here to help" and he was right, especially when the IRS is involved. That said, occasionally a government agency does help and a recent document published by the National Institute of Standards and Technology (NIST) clears up a topic that really matters to all of us: How passwords should be built.

 

 

In June this year, NIST published its latest version of Digital Identity Guidelines and in section 5, Authenticator and Verifier Requirements, subsection 5.1.1, Memorized Secrets, the draft addresses something that's been argued about forever.

"Wait! Memorized secrets?" you might be asking. "Is that government-speak for passwords?" Yes! Got it in one! Let's review their definition (the bolding is mine):
 

A Memorized Secret authenticator — commonly referred to as a password or, if numeric, a PIN — is a secret value intended to be chosen and memorized by the user. Memorized secrets need to be of sufficient complexity and secrecy that it would be impractical for an attacker to guess or otherwise discover the correct secret value. A memorized secret is something you know.


Never was a truer word spoken; passwords do, indeed, need to be "of sufficient complexity" (what most of us refer to as "strong"), which begs the question: what constitutes a password of sufficient complexity? The password policies of many organizations require some combination of minimum length, use of both upper-case and lower-case letters, one or more numeric digits, and one or more special characters (i.e. @, #, $, and so on). In addition, some policies also require things such as regular password changes and ban the use of blacklisted passwords (see, for example, the Real-time Password Blacklist).

There's also another issue about passwords: How easy is it to create a password? Consider how often you've registered on some site or in some application only to be told, after entering a password you thought was okay, you need more characters or that a special character is required or that some special character can't be used? This … let's be kind and call it "flawed" … user experience becomes an infuriating multiple entry trial and error process as you try to satisfy all the requirements.

Now, some people might think these constraints sound sensible, but are they really practical and effective? In subsection 5.1.1.1, NIST recommends "Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber," so many of you have been correct on minimum length. But wait! There's more! In subsection 10.2.1, NIST's new guidelines suggest:
 

When users create and change memorized secrets:
     Clearly communicate information on how to create and
     change memorized secrets.
     Clearly communicate memorized secret requirements, as
     specified in Section 5.1.1.
     Allow at least 64 characters in length to support the use of
     passphrases. Encourage users to make memorized secrets as
     lengthy as they want, using any characters they like
     (including spaces), thus aiding memorization.
     Do not impose other composition rules (e.g. mixtures of
     different character types) on memorized secrets.
     Do not require that memorized secrets be changed arbitrarily
     (e.g., periodically) unless there is a user request or evidence
     of authenticator compromise. (See Section 5.1.1 for additional
    information).
Provide clear, meaningful and actionable feedback when chosen passwords are rejected (e.g., when it appears on a “black list” of unacceptable passwords or has been used previously).


So, to sum up the NIST guidelines, in addition to explaining clearly what is acceptable and what isn't, passwords …

  • Must have a minimum length of 8 characters
  • Must allow for a maximum length of at least 64 characters
  • Must not be constrained by composition rules
  • Must not require being arbitrarily changed

That's it! That's all that's needed to build robust passwords without giving people the user experience from hell. And note that NIST hasn't just made these guidelines up; they're the result of serious study by many industry professionals and embody a "best practices" approach to password security by balancing effectiveness and usability. Any other bells and whistles you might add to your password policy are, in essence, pointless and, in the case of consumers trying to establish an account that requires unnecessarily complex composition rules or doesn't explain up front what the rules are, damaging to your brand.

Isn't it great when the government actually helps? I wonder how long it will take federal agencies to adopt the NIST guidelines.... I'm looking at you, Attorney General of Texas (from their Child Support web site):

Image Source: Attorney General of Texas Child Support web site

Image Source: Attorney General of Texas Child Support web site

In the next Gearhead column we'll look at another and much bigger problem: How your staff can destroy your organization.


Comments? Thoughts? Drop me a line then follow me on Twitter and Facebook and sign up for my mailing list!


About Mark Gibbs

Mark is the author of four best-selling computer networking book titles and was a syndicated journalist and columnist for 24 years writing for Network World, Computer World, and other IDG publications. Mark is now the column editor for The New Gearhead here on ITSPmagazine.

More About Mark