Password Management – Best Practices in 2018

April 29th, 2018

passwordguytitle copy

 

Introduction

 

Giving users a secure way to access applications (any kind of application, mobile, web, desktop, cloud) has been a key function of every system I have built in my career. Most applications traditionally utilize a user and password as a way to “authenticate” and provide secure access to a system. Recently you may have noticed a “2nd factor” being used to access the applications you may deem important such as a bank or a brokerage. Often this “2nd factor” comes in the form of a token that is emailed or sent via text message to you. The best practices for how we build secure access into a system has changed quite a bit in the last few years. The goal of this article is to discuss current best practices and how they have changed, and the reasoning behind them so that end users, not only those who design systems, have an understanding of the topic.

 

Key Concepts

 

When we design secure access to systems, we have lots of things to think about. This section reviews the key options we consider during the design process.

 

When looking at password best practices, typically we think about the following:

 

Password Dissemination:

  • How is the password set up and given out (is it set by the user themselves, is it emailed, snail mailed, hand delivered on paper)?
  • How is the password reset?

 

Password Complexity:

  • How long is the password (how many digits)?
  • Does it contain numbers and letters (more possibilities)?
  • Does it contain special characters (even more possibilities)?
  • Is it case sensitive (even more possibilities)?
  • Does it contain common words or names (easy to guess)?

 

Password Durability:

  • How long does the password last?
  • Can previous passwords be used?
  • Hints (do we allow password hints)?

 

When designing for overall secure access we can consider additional items beyond passwords including:

 

  • Multi-Factor Authentication (MFA or 2nd Factor) – biometric, certificates, key fobs, text message tokens, email tokens, knowledge based (e.g., mother’s maiden name).
  • Account lockout from bad tries (of passwords and 2nd factors) (Auto Unlock).
  • Usernames (email, non email, recovery).
  • Auto Logout (session timeout) after a period of time.

 

password3

 

Security Tradeoffs

 

Security is always a tradeoff between ease of use, cost and how secure something can be. Take banks for example. If we really wanted banks to be very secure, we would have less of them and the ones we have would have mantraps, metal detectors and armed guards. We rarely see these things at banks, mainly because banks want their services to be convenient for their customers. They want a branch on every corner, they want easy quick access for their customers and they don’t want their customers to feel unsafe. On top of this they need to keep costs reasonable. At the same time there are things banks can do like keeping less cash on hand, silent alarms, and cameras that are not “intrusive” to the customer and have a reasonable cost to implement.

 

Taking our bank analogy online, we can take the complex choices on all of the items I outlined above and have pretty good “secure access”. The downside of this is customers may become frustrated with the complexity and take their business elsewhere, or worse, they can short-circuit the best of intentions by doing things like writing their password down on a sticky note and putting it on the monitor (how many times have we seen this at our parents’ house).

 

Another example of tradeoffs is one I experienced years back when I was the architect of an online brokerage system. I insisted that we have serious password complexity minimums including case sensitivity on our passwords. I won the initial battle with our head of customer service, but after we were live for about six months, he took his case to the CEO and showed how much the password complexity was costing his team in calls from customers. The CEO asked me to back off the complexity requirements and remove the case sensitivity. This lowered our security somewhat, but I was able to keep the passwords at a reasonable length balancing security with ease of use and cost.

 

Application Best Practices

 

The National Institute of Standards and Technology (NIST) is a U.S. government organization that sets standards for the U.S. government. Conventionally, many application developers in both government and the commercial space use these guidelines when implementing applications.

 

Traditionally (and prior to June 2017 when new guidelines were issued), best practices were to weigh security over user friendliness and:

 

  • Have long, complex passwords that have numbers and special characters.
  • Force resets (as often as monthly).
  • Have password hints for remembering these complex passwords.
  • String together common words to make passwords easier to remember.

 

In June of 2017, NIST released new guidelines that surprised many of us. The guidelines were released in NIST Special Publication 800-63-3. The summary of these guidelines and their changes to passwords are:

 

  • Only require passwords that are at least eight characters but allow them to be up to 64.
  • Allow all unicode characters, but don’t require things like one lower or one upper case character or one number or four symbols.
  • Don’t allow common “dictionary” words as part of the passwords.
  • Remove password hints.
  • No more password expiration (unless there is a reason such as a breach).

 

Another change the NIST suggests is to stop using any option that is not activated through a memorized secret or biometric device when using 2nd factor. This implies we should stop using tokens sent via email and SMS text message. We should also stop using question/answer (knowledge) based solutions. This leaves us with less options; the most common would be a key fob with biometric activation, or app on our phone with biometric activation (thumbprint). Common applications are Google Authenticator and Authy.

 

As you can see, the theme from these guidelines is to be more “user friendly” which ultimately leads to a more secure system. One of the most insecure things we do is “resetting” passwords, as these reset tokens and links often travel over insecure transports (text and email). By reducing password changes, we are increasing the overall security.

 

All new systems should consider the changes to NIST-suggested best practices and use them during construction. End users can help by not short-circuiting best practices and by using a password manager and hard-to-guess usernames.

 

User Best Practices

 

The old saying “it takes two to tango” applies in secure authentication. Application designers can do everything in their power to follow best practices and design secure authentication, but end users can easily short-circuit these best practices. Common things that end users do that they should not, include:

 

  • Putting passwords on a sticky note.
  • Emailing or texting their passwords to a friend.
  • Using the same password (or variation of a password) on all their applications.
  • Saving their passwords to their web browser (worse on a public computer).
  • Using overly complex passwords that they can’t remember that require frequent resets.

 

So what is the solution to this problem? Strong passwords are hard to remember and having a different one for each application would require me to remember 100 passwords. The best option is to use a “password manager” or “vault”. Password managers allow you to securely store all your passwords in an encrypted vault. This “vault” can be shared across all your devices and only opened using biometric or one complex password. Password managers can also generate secure (different) passwords for each of your applications. Two popular password management software makers are LastPass and 1Password.

 

Back in 2016 I didn’t use a password manager for all of my accounts. I did use secure passwords for any applications that I thought “mattered” but for other applications I used a pretty simple password. One morning I received an email that I had booked a couple of flights in Asia using my Marriott rewards account points. Twenty years ago when I started my rewards account I used a simple password because I never thought the account would be worth much. However, in 2016 I had accumulated over 100k rewards points using my credit card and hotel stays to save for that dream vacation. I was a big target for the bad guys! Luckily I acted quickly when I received this email and worked with Marriott to lock my account and cancel the purchase.

 

Another step users can take is to use a different username for each account. Most people use their email or some combination of their first and last names/initials. These are easy for the bad guys to guess. This can be difficult if applications require emails as usernames. There is a handy trick that can help users that use gmail. Gmail has a feature where you can add a “+” sign after the first part of your email address but before gmail.com to create as many email addresses as you want. For example, with an address of myuser@gmail.com, I could create myuser+marriott@gmail.com for my Marriott account (actually, I would use something more ambiguous like myuser+mrw@gmail.com).

 

Conclusion

 

Today the majority of applications were built using the old standards of secure authentication. It will be some time before the owners of these applications become aware of the new best practices and find the budget and time to update their systems. All new systems should consider the changes to NIST-suggested best practices and use them during construction. End users can help by not short-circuiting best practices and by using a password manager and hard-to-guess usernames.