Forgotten Passwords: The Bane of the Admin's Existence

The company I work for evaluates residents for enrollment in government-run healthcare programs. In order to do their job, our employees must have credentials for our local domain, applications housed at corporate headquarters, and various legacy systems run by the state. Each employee has more than half a dozen sets of credentials to keep track of. Consequently, the following dialog is seen frequently:

End User: I changed my password and now I’m locked out.

Admin: Which password?

End User: My computer password.

Admin: WHICH computer password? Would this be your Windows^®, Outlook^®, AppA, AppB, AppC, or your AppD password?

End User: They’re all the same.

Admin: That can’t be since they’re all different credentials that expire at different times and have different requirements. For instance, Windows and Outlook require you to include special characters, but AppC and AppE don’t understand special characters. Windows, Outlook, and AppA require that you choose a new password every 60 days, AppB and AppC every 90 days, and AppD doesn’t let you change your password at all.

End User: Oh, if did a Control-Alt-Delete and picked “change a password,” which one did I change?

Admin: That would be your Windows password.

End User: Well I tried that password three times for AppA, and now I’m locked out.

Admin: I can reset that for you.

End User: How about AppB?

Admin: You’ll need to call the corporate help desk.

End User: How about AppC?

Admin: You’ll need to call the state help desk.

Conflicting Requirements for Passwords

Yeah, it can get ugly; different systems, some old, some new, some run by different organizations. Some are built around password requirements from 1993, while others use password requirements from 2003. Oddly, it turns out that one set of practices isn’t much better than the other. In the early 2000s, the National Institute of Standards and Technology (NIST) guideline told us to adopt practices such as: making our passwords nonsensical and complicated, using letters (upper- and lower-case), numbers, and special characters ([email protected]#$%^&*()_),  changing our passwords regularly, and using different passwords for each app and website.

Unfortunately, while those guidelines make some technical sense, they caused all kinds of security problems due to human behavior. That’s a big problem since human behavior is the weakest link in the security chain already. People can’t keep track of all that complexity, so what do they do? They use the same password on as many systems as possible. When they have to change it every 30 days, they just use the name or number of the current month in the password. When they have to include a special character, they put an “!” at the end. And worst of all, passwords get written down and stored in the top right drawer or under the keyboard of almost every desk. Yet even with all that, Admins still spend a large portion of each day helping locked out users get back in.

NIST to the Rescue

Thankfully, NIST is in the process of making our lives easier with this year’s Special Publication 800-63B Digital Identity Guidelines. This includes recently revised guidelines for creating passwords, and this new advice rejects many of the principles behind its 2003 recommendations. The new guidelines run along the lines of keeping passwords simple, long, and memorable. Things such as sequential characters and repeated characters are still discouraged, as are things like over used passwords (your name, [email protected], etc.). But using phrases that make sense to you is encouraged. And passwords never need to expire.

Now, while NIST no longer recommends special characters and numbers, I’m still a fan of using common sense complexity in passphrases. Something like “Meet for dinner @ 7 P.M.” makes sense, is easy to remember, and has complexity. If a particular authentication system doesn’t understand blank spaces, then the passphrase can be “[email protected]” Following this advice benefits you in two ways, both by making it easy to remember your passwords and strengthening them. 

So join me in bringing about a better password future and in hoping that the new NIST guidelines are adopted quickly in our industry.

 

Dan Toth is an information systems specialist with a proven background in the development and management of systems, projects, and personnel. Dan’s particular areas of strength include Network Management, Healthcare-Related Computer Systems, Technical Training, and Information and Physical Security.

 

For more blogs on password management, click here.

 

© 2017 SolarWinds MSP UK Ltd. All rights reserved.