Make A Resolution: Kill Your P@55W0rD Policies

It has finally become hip not just to predict the demise of passwords, but to call for their elimination. The recent Wired article makes an eloquent case about the vulnerabilities that even "strong" passwords are subject to, such as social engineering and outright theft. And strength is, of course, relative and subject to degradation: The latest computer hardware can make short work of cracking more-complex secrets.

It's true: Static shared secrets are sitting ducks. But passwords are too useful to go away entirely, both because it's handy to be able to synchronize authenticator data between cooperating systems (and people), and because people find using passwords to be less invasive, fiddly, or personally identifying than a lot of other options. So I don't buy the whole "the era of passwords is over" thing. They will be at least one important element of authentication strategies for the foreseeable future -- it's a rare multi-factor authentication strategy that doesn't include a password or PIN somewhere along the line as one of the "things you know."

So, if that's our reality, let's think outside the box in using them. In talking with Mike Gualtieri recently as part of his TechnoPolitics podcast series, I mentioned a few ideas. I had thought of these as pet password peeves, but on the cusp of 2013, why not be positive and think of them as resolutions?

Don't depend on passwords alone for sensitive operations. Leverage risk-based authentication (see our RBA Wave) to put multiple authentication factors into play in a way that inconveniences your users as little as possible. eCommerce and banking sites already do this heavily. By the way, how often have you changed your Amazon password? (I give my answer over in Mike's post.) When you accept passwords but don't bet the farm on them for assessing risk, funny things -- funny good things -- can happen to both risk management and usability.

Stop forcing users to thread the needle of your password policies. Password policies are well intentioned, but often misguided. Your goal in imposing them is to make users choose passwords that are harder to crack. Their goal is to defeat the unmemorability of the resulting string. This misalignment of goals means you get strings that pass your test but have limp-noodle bit strength because they're entirely predictable and already listed in dictionaries, like P@55W0rD -- along with causing your users to swear and gnash their teeth. This great paper on password policy theater from Microsoft Research explains how "Much of the extra strength demanded by the more restrictive policies is superfluous: it causes considerable inconvenience for negligible security improvement." Why not pick your users' passwords for them by applying a random password generator? Some offer mnemonic help and settings for increased memorability, and you know everyone was writing down their passwords before anyway. Goal misalignment solved.

Consider "push" models for refreshing user passwords. People really, really hate changing passwords. That's because we've put the onus on them to do all the work: Go to some special app, choose a new password that meets the silly policies, and wait for it to propagate everywhere. And yet, if you do depend on passwords for significant risk mitigation, rotating secrets is one of the most important things you can do. As the Agile developers say, "If it hurts, do it more often" so that you can surface and fix issues. Interestingly, we already have a real-world example of passwords that are easy to refresh as often as we like: one-time passwords. They solve these issues by using a push model to send the secret to a user's previously registered alternate channel. What if we make it this easy to refresh users' "static" passwords, that is, passwords with a longer-than-momentary lifetime? Once we put ordinary passwords on the "refreshable" continuum, we've begun to shape a new future for passwords that isn't as bleak.

Comments

I’m not sure that having a

I’m not sure that having a new static password pushed out to an alternate channel such as a cellphone, on a regular basis, would be the optimal solution. I’d still need to transfer that new password to my password manager, which doesn’t reside on the alternate device. That could be an annoyance for someone receiving regularly refreshed passwords from many relying party sites.

The real problem with passwords, at least as they are commonly used today, is that they’re shared secrets. So there’s always the possibility of a breach. Public key cryptography provides a way to do strong authentication without shared secrets. That was the original vision of SSL/TLS. I might still use a password or PIN to unlock a private key on my device, but the password/PIN never leaves the device. But until recently, not much effort has been devoted to making public key cryptography usable for consumer authentication. Now, at least one Silicon Valley startup is making real headway in this area. Widely adopted and usable strong authentication based on public key cryptography is what I’d like to see replace shared secrets.

The Wired article reveals that reliance solely on shared secrets for authentication is not only a bad idea, but that these shared secrets are not limited to passwords. The article describes how “social engineering” was used to hack into sensitive accounts. So not only do we need to stop using shared secrets to authenticate people online, but we need to stop allowing bad guys to impersonate us over the phone if they happen to know four digits of a credit card number or social security number, or the answer to a challenge question. Unfortunately, the article loses me when the author suggests that the answer is “real identity verification: to allow our movements and metrics to be tracked in all sorts of ways and to have those movements and metrics tied to our actual identity.” That’s a privacy concern. I’d rather just have each of my devices tied to my (actual or pseudonymous) identity at each relying party site in some cryptographic and privacy-protecting way that doesn’t involve shared secrets.

Shared secrets as the only authenticator

Hi Bob! Agreed that shared secrets have major weaknesses. The problem is, they are also expedient -- certainly more so than asymmetric key approaches. So for a variety of circumstances (just trying to be realistic here), they'll be the solution of choice, or at least part of it -- e.g., unlocking mobile devices. :) We'd best not use them as the only "gate" for access to sensitive stuff (which is most stuff), and try to shore up structural weaknesses in how we select secrets today.

As one commenter in private email noted to me, consolidating authentication services to get single sign-on can help with the password plethora problem; you allude to that as well in talking about having lots of passwords all needing to be refreshed. But SSO, if it's protected with just a password, is a nod to user convenience that weakens your risk mitigation because it's a single point of failure. SSO and strong auth are like peanut butter and chocolate in this respect (that is, synergistic :-) ).

Also agreed that a ubiquitous real-world identity verification strategy is dangerous. As that too gets more expedient (look at all the new "social verification" startups), it will insinuate itself into routine authentication a lot more, which is unfortunate.

passwords are here to stay

Within the fire-walled confines of our corporate network, I have to change my email/Windows password every 90 days. I don't know why. I really don't mind anyone reading my work email, no real secrets there. And if they want to access my shared folders on the network, have at it, maybe someone will find that document I lost a few days ago.

But passwords to access any of my personal assets held at some of the largest American banks and investment houses, never expire.

Why?

I believe because the banks and investment houses will lose customers if they require them to change passwords every 90 days. Banks will continue to rely on the good old password, because it is *so simple*. Asking a customer to use two factor auth or biometric will increase the complexity of a web transaction and drive customers away.

One tool in the toolbox

Hi Jonathan-- Thanks for writing in! I would say they continue to *use* the good old password, but almost to a one, they also extensively use risk-based authentication in the background as the kickoff of a multi-factor fraud management process. In the US, the FFIEC guidelines (really regulations) started mandating multiple factors several years ago, and banks hunted for the best-quality fraud management that would be compliant and would impact users the least -- and found RBA.

If you take a look at the linked Microsoft Research paper, it points out sort of what you're saying: We have less usability at sites that are insulated from bad decisions and mistakes around usability -- e.g. the .gov sites they looked at, and, I would also argue, inside the enterprise where you have a captive audience. The scary part is that sites and apps with bad usability don't guarantee security. :-)

(Some high-risk/high-value banking use cases around the world *do* mandate the use of things like hard tokens...)