Stop Changing Your Passwords

Everyone knows the password drill at this point. Don’t use words in the dictionary. Don’t share your password. Don’t use just letters, mix in numbers and special characters. Don’t use the same password for different websites or applications. Then change them every (insert your favorite number here) days. Oh, and don’t write any of them down - you need to memorize them all. Really? Have you ever tallied the number of accounts your average user has to keep track of?

• Active Directory
• Voicemail Password
• That miscellaneous 3^rd party web application or two
• The secure mail password your partner company requires you to use for HIPAA emails
• The old document management portal that was supposed to be deprecated 3 years ago
• The old Access database that accounting has to open up once in a while to check on old orders

Let’s take that likely conservative estimate of 7 passwords. Now change them every 90 days, you’re looking at 28 passwords to memorize over the course of a year – doesn’t sound that bad after all. But wait, these users have lives outside of work – there’s Facebook, personal email, Twitter, their Dunkin’ Donuts account, Speedpass, Sam’s club, and dozens of other sites and accounts to keep track of. I use a password manager myself (more on that later), and I have 455 different sets of credentials stored at last count. Culling that number down to account for duplicates or stale accounts - and also taking into consideration that my unhealthy computer-addiction makes me a bad example here - and you’re still looking at around 100-150 accounts.

The reality of this approach is that it’s broken. We all like to complain about users, and shake our heads when we see post-it’s on cube walls with passwords scribbled on them, but if you really think about it, that’s a situation of our own making. It’s unrealistic to expect users to follow the ever-expanding list of security rules described above, and if you’re trusting that to keep your network safe, best of luck. Too often, IT support forgets to employ a little empathy, and consider things from a users’ perspective. Users don’t want to have all these accounts, and micromanage IT ‘stuff’ - they just want to get their jobs done. Every time something breaks, like an account getting locked out, that user is under greater pressure with their superior. They’re on the hook to produce, and if it comes down to their job or IT security, they’re going to choose their job. Wouldn’t you? Tell me you’ve never taken a shortcut to meet a deadline.

“Not my problem” is one approach. I get it, most of us in IT are swamped with too much work and not enough bodies, and you can’t secure the entire internet after all. So you apply the aforementioned best practices within your small island of control, and call it a day. That’s what most of us do, because it’s all we can do. Or, more accurately, it’s all we perceive we can do.

Since I’ve been blathering on for too long already, let me buy some time with an entertaining comic from the internet-famous XKCD, by the renowned Randal Munroe:

For starters, dispense with the notion that your password is somehow no longer trustworthy after 45/60/90 days. What happened at midnight of the night of the 89^th day that turned your password into a pumpkin? If your rationale is to close down access to users’ passwords that may have been compromised by a malicious agent (or, perish the thought, shared with others intentionally) are you really willing to wait up to 90 days to address that? Or 60, or even 45? Are you sure the odds of an 89 day old password being compromised are that much higher than a 1 day old password? Because I’m not. If anything, it’s the other way around. Once a user remembers their password, the post-it often goes in the trash. I have seen users write down a new password - after being forced to change it - where there previously was no paper copy of a password in sight. The new password was at higher risk. If you’re still not convinced, consider that Bill Burr, the author of most of this password handling dogma, is on my side now too. In a recently published interview for the Wall Street Journal (paywall), he admits that his 14 year-old advice is no longer an effective strategy. NIST has even updated their official policies about a year ago, here.

The way I see it, is that if we took a different approach that lessened the burden on users, we would have an easier time enforcing it. Like the old saying “With children and dogs, have as few rules as possible, but stick to them consistently”. This is not a dig at end users. We all have the capacity for human error, so it’s not going away. When planning IT infrastructure we go to great lengths to minimize single points of failure. Why not with security policy. Every rule you try to enforce with users, introduces the potential for human error, i.e. failure of the policy.

So, let’s make things simpler. Mind you, these suggestions are strictly based on my personal opinion and experience, and if your industry is regulated your hands may be tied in some cases.

1. Passwords don’t expire, they’re changed when there’s reason to suspect foul play
   1. Examples would be after a malware/virus infection, or unusual account activity
2. Worry less about password complexity, and more about length
   1. For example:
      1. ‘Saf3ty!’ – can be cracked in, at most, 6 hours, 20 minutes
      2. ‘safetyisgreat’ – 28 years, 1 month

• ‘This is an easy to remember password’ – years, scientific notation; ‘nuff said

(You can try this yourself at http://random-ize.com/how=-long-to-hack-pass/)

3. Allow 10 attempts before locking out accounts
   1. The objective is to block brute force attacks, not legit users that didn’t have their coffee yet. If a hacker can crack your passwords within 10 guesses, you’re doing it wrong, go back to step 2
4. Use integrated security whenever possible (LDAP for example)
5. Allow the same passwords for different applications
   1. If you trust a password for Application A, then it should be trustworthy for Application
   2. Use two-factor for particularly high-value targets
6. Use limited access accounts for your IT staff, with secondary domain admin accounts when elevation is required – I’ve lived this, and it’s not nearly as bad as it sounds at first
7. Limit visibility of service account passwords as much as is practical, limiting disruption to operations when you inevitably change them due to turnover

Lastly, I would urge you to seriously consider using a password manager, at least for your IT staff. There’s quite a few to choose from, and if anyone needs help keeping track of passwords in a secure encrypted manner, including the ability to share portions of the credentials database with different user groups.