The days of long, complicated passwords are over

Recently, Microsoft published a new password policy recommendation paper containing advice that flies in the face of conventional wisdom on the subject. Some of the contrarian viewpoints include:

• Eliminate long password requirements
• Eliminate complexity requirements
• Do away with password life expirations

Along with this unconventional advice comes a bunch of useful suggestions:

• Ban common passwords
• Eliminate password reuse
• Enforce multifactor authentication
• Enable risk-based, multifactor authentication challenges

Altogether, this is one of the more useful password references I’ve seen in a long time. If you ask me, some of these updated recommendations are overdue. To understand why, you need to know a little about how guidelines for passwords have evolved.

Conventional password wisdom

Traditional password recommendations, as implemented by most companies, typically call for passwords at least eight to 12 characters long, complexity that includes at least three different character sets (letters, uppercase, lowercase, numbers, symbols, and so on), and the stipulation that passwords should be changed at least every 90 days.

It has taken most companies decades to implement those recommendations rigorously. Moreover, those same companies probably still have a system or two on which they were unable to enforce the policy.

How have users dealt with those password rules? They grudgingly moved from short, six-character passwords with no expiration date or complexity to long, complicated strings. That move made it hard for most people to remember what they chose for a password, a problem best captured in a now classic XKCD cartoon.

How password problems have changed

After the initial pain of using longer, more complex, more frequently changed passwords passed, users have for the most part accepted it as a way of life. Implementing those recommendations actually decreased the risk of password guessing/cracking.

But over the last decade, hackers have changed the way they attack passwords. Back in the day, most password attackers literally guessed at user’s passwords. They found an externally accessibly portal where they could guess using manual or automated methods — or they found the password hash and used rainbow tables to convert passwords back to the plaintext equivalents.

Today, almost all password attacks are one of two types. Users are either socially engineered (phished) out of their password, or the attacker steals their hash and uses it during other authentication attempts. In both scenarios, long and complex passwords offer little protection. Yes, some attackers and malware still try to guess passwords, but they’re now in the minority.

New password attack methods require new policies.

Eight (to 12 characters) is enough

If you use account lockouts after X number of password tries — or monitor for and alert on instances of very fast, automated password guessing — passwords of eight to 12 characters are long enough in most instances. You can add complexity requirements, but it doesn’t increase protection by much anymore. (In fact, as the XKCD cartoon illustrates, it can be detrimental.)

I’ve registered at a few websites lately where users are unlikely to enter sensitive information. There’s no reason to require extra complexity — yet these sites demand passwords containing four or five character sets! It’s truly insane. I end up with a  gobbledygook password I can never remember.

Let’s use our passwords longer

Today, many companies require new passwords every 45 to 90 days. I say that forcing changes every 120 to 180 days is fine. I’ve seen a few companies push forced password changes to one year without any increase in password hacking issues.

That said, I still think highly privileged accounts should have their passwords changed very frequently, perhaps as often as once per day or once per use. It virtually assures you’ll need additional software to accomplish this, but since those accounts are the ones attackers target, it makes sense.

Don’t reuse passwords across security domains

This recommendation is huge — and hard to enforce. When you reuse passwords across security domains, websites, or various services, you increase your hacking risk exponentially. Many big, recent hacks have occurred due to password reuse.

Many companies even download (or subscribe to a commercial service that downloads) illegally obtained website password databases to see if their employees’ passwords are located in them. If so, the employee gets a warning — and may even get fired.

Use risk-based scenarios

I’m particularly enthusiastic about the recommendation to implement risk-based, multifactor authentication challenges. It makes sense that higher-risk scenarios should require greater authentication assurance.

For instance, if you log into your email account from your normal computer from your normal location, it may even be OK to allow some sort of autologon using a stored, simple password. But if you try to log on to the same email account from a new computer in a new country, you need stronger measures. Hotmail works this way for me right now: I use a simple password on my own computer at home, but if I log on to the same account from a new hotel, I need to enter a PIN sent via text to my phone.

Microsoft’s risk-rating mechanism is even smart enough to recognize that I’m a frequent traveler, so I don’t get asked for the second-factor PIN all the time now — only when I’m in high-risk areas or if I’ve traveled very far, very quickly from my last logon location.

Problem with password policy changes

I’d love to see these these new password policies implemented overnight. Unfortunately, most companies are forced to apply traditional password policies by one or more regulatory agencies, regardless of what Microsoft or any other vendor recommends.

It took decades for the regulatory bodies to implement those outdated requirements. It will probably take a decade for those same regulatory bodies to accept any new, improved password policies. Even if we decide want to implement a new set of password policies — and even if those changes are backed up by data — regulations will lag far behind and can prevent change from occurring.

Some of those legacy rules are pretty stupid. For example, a six-to-eight-character complex password would be acceptable according to most regulatory policies, but none allow a 42-character, noncomplex, easy-to-remember password made up of a random series of words, even though the latter is inarguably more resistant to attack.

It reminds me that there’s often a difference between security policy and true security. One is an unyielding dictum, the other is faster and more flexible in the face of new attacks and facts.

Nonetheless, we all need to rethink what our password policies should be. We and our regulators need to move as quickly as our attackers.