Password complexity rules are out of date

We are all familiar with systems that force the user to select a password using a complexity rule.  You know, the rules that say that the password is required to contain an upper case letter and a lower case letter and a numerical digit and at least one character that requires at least two hands to type on a keyboard.

And we are all familiar with systems that force the user to change his or her password frequently — every few months for example.

It turns out that these rules are outdated and should be scrapped.

Prime examples of systems imposing such rules are the Financial Manager system that USPTO rolled out a year ago.  And the EFS-Web/PAIR system that USPTO rolled out maybe a decade ago.

You might wonder where those requirements came from.  The chief source was a document published in 2003 by the National Institute of Standards and Technology.  For many decades, NIST has been a sort of go-to place for Best Practices for system security, password standards, and user authentication rules.

As many old-timers will recall, the old rule years ago was that if you were buying a computer system, “nobody ever got fired for choosing IBM”.  And years ago if you were buying a telephone system, “nobody ever got fired for choosing AT&T”.  Well, for decades it has been the case that if you are setting up a login mechanism for a secure computer system, the rule has been “nobody ever got fired for following the NIST recommendations.”

And indeed nobody has ever been fired for following the NIST recommendations.  The 2003 document had the catchy title of “NIST Special Publication 800-63”.  And this document, written by a fellow named Bill Burr, turns out to be the reason why so many system designers force you to include a smiley face in your password regardless of whether you think you need it or not.  This document turns out to be the reason why so many system designers force you to change your password every few months, regardless of whether you think you need to change it or not.

Fourteen years have passed, and NIST has published a revised version of this Special Publication.  The new version is dated June 2017, and you can see it here.  The document is written in a dry government-agency style, but here are two of its recommendations for system administrators, translated into plain language:

• Stop it with the annoying password complexity requirements.
• Stop it with periodic forced password changes.  Only force a password change if there is some indication the password has been compromised.

Security experts such as Bruce Schneier have been making these two points for years.  Now that NIST has weighed in, having said “never mind” about its 2003 recommendations, there are no more excuses for sticking with the old requirements.

One hopes that USPTO people will read the NIST report and will adopt more modern Best Practices for user login security.  Most urgent are:

• For EFS-Web/PAIR:
  • scrap the Entrust java applet login method
  • scrap the forced password complexity rules
  • adopt a modern two-factor authentication approach
• For Financial Manager:
  • scrap the scheduled forced password changes
  • scrap the forced password complexity rules
  • adopt a two-factor authentication approach

As for present-day Best Practices for two-factor authentication, the best choice for USPTO to adopt would be a U2F (Universal 2nd Factor) approach.  Failing that, the next-best approach for USPTO to adopt would be a TOTP approach (Time-based One-Time Password).  An example of the latter is Google Authenticator but there are many other apps that support TOTP.

Probably the best path for USPTO would be to get out of the business of trying to figure out how to authenticate its customers.  There is a system called Login.gov which is shared by many government agencies, as a way to outsource the business of managing user passwords and two-factor authentication and such.  For example the Customs and Border Protection folks, who administer Precheck and Global Entry and Nexus and Sentri, recently scrapped their legacy system for administering passwords, and outsourced this function to Login.gov.  The transition happened on October 1, 2017.  I use Precheck and Global Entry and Nexus, and and I found the transition to be smooth and seamless.

Login.gov is pretty smart about two-factor authentication, for example having implemented TOTP authentication (meaning that for example you could use Google Authenticator or a similar app).

USPTO already got out of the business of trying to receive credit card payments.  Years ago USPTO outsourced this to Pay.gov.  So far as I can see, this outsourcing of credit card payments has worked out just fine for USPTO and for customers.

Maybe the smart choice would be for USPTO to get out of the business of trying to design and develop and administer passwords and two-factor authentication.  Maybe Login.gov is the way to go for the USPTO.

Of course for any government agency it is institutionally difficult for anyone to admit that any other government agency would know how to do something better.  It is institutionally difficult to think that anything that was “not invented here” could possibly be the right way to do something.  But somehow USPTO was capable of overcoming these institutional biases to choose to outsource credit card payments.  Maybe USPTO could similarly overcome these institutional biases to choose to outsource the administration of passwords and two-factor authentication.

What do you think about USPTO’s use of the Entrust java applet for logging in at EFS-Web and PAIR?  Please post a comment below.