Within This Decade

Security professionals have known for many years that your password is one of the weakest points in the security of the web of computing devices and services you use.

We’ve been trying to do something about the problem for as long as I’ve been in the business.

We started by obfuscating passwords on servers after we figured out that the password file was an attractive target for attackers. UNIX was a pioneer in this area, though as usual MULTICS was there first.

Obfuscating and encrypting passwords has never worked very well, because a large percentage of passwords are very easy to guess in just a few attempts.

But protecting passwords on servers didn’t work for another reason too: you could read them off the network as they zipped by. We’ve tried encrypting them on the network (TLS became an IETF standard in 1999, by which time its predecessor SSL had already been in use on the Internet for three years), and we’ve tried pushing their use to the client system to keep them off the network entirely (Kerberos became an IETF standard in 1993, by which time it had already been in use at MIT and elsewhere for many years).

Keeping passwords on the client assumes a bunch of things which aren’t true. It assumes clients are secure; they aren’t. It assumes passwords aren’t trivially easy to guess; they usually are. And it assumes that the user won’t tell the password to anyone who asks. Phishing attacks are what you get when the bad guys figure out that you will tell your password to anyone who asks.

It’s bad enough that passwords aren’t very secure; what’s even worse is that they’re a huge pain too. We all hate them because we have to change them all the time and they’re hard to remember. Your organization probably has a bunch of rules for good passwords: they have to be at least “some number of” characters long; they have to include a bunch of weird characters you can’t find on your keyboard; you’re not allowed to use your name, or your account name, or more than two characters from your last password - and so on. All these rules are just variants of the Two Platonic Password Composition Rules:

1. Pick something you can’t remember.
2. Don’t write it down.

No problem, right?

We security guys have known for a long time that the right way to deal with passwords is to get rid of them. We resolve to do it periodically, but these resolutions are like New Years’ resolutions to lose weight - somehow we never get around to finishing the job.

In 1998 the Internet Architecture Board got a bunch of us together to take a look at what the security architecture of the Internet should look like. We agreed on almost nothing - with one exception:

“One security mechanism was deemed to be unacceptable: plaintext passwords. That is, no protocol that relies on passwords sent over unencrypted channels is acceptable.” IETF RFC 2316, 1998.

Eight years later lots of websites still ask for your password over an unencrypted HTTP connection (but giving examples wouldn’t be nice).

In 2003 the National Academy of Sciences got a bunch of us together to take a look at authentication technologies and how they affect your privacy. Unsurprisingly, we agreed again:

“Static passwords are the most commonly used form of user authentication, but they are also the source of many security weaknesses... great care should be taken in the design of systems that rely on static passwords.” “Who Goes There?”: Report of National Academy of Sciences Panel on Authentication Technologies and Their Privacy Implications, 2003.

The report doesn’t come right out and say we should just get rid of passwords - because at the time I argued passwords were still OK in some contexts and that an out-and-out ban would be an overreaction to the risk.

I was wrong.

Static passwords are an unacceptable hazard, good alternatives exist, we should get rid of static passwords in favor of those alternatives, and we should do it fast.

We’ve been saying this for years; it’s time to get off our butts and do it. Bill Gates agrees; in his keynote address to the RSA Conference last week, he called passwords "dinosaurs", and noted that they're becoming the weak link in the security of the Internet.

As penance for my past sins, I’m going to issue a challenge to the information security community from my little soapbox here:

“I believe that this community should commit itself to achieving the goal, before this decade is out, of providing every computer user with a strong authentication device and the infrastructure required for its universal acceptance.”

What do I mean by “a strong authentication device”? It’s a device with the following properties:

1. It’s always with you
2. You notice quickly if you lose it
3. No one else has one exactly like it
4. It keeps a secret you can’t remember without writing it down
5. It never does the same thing twice

Why these characteristics and not others? Because: if your device never does the same thing twice and no one else has one exactly like it, you need to have your particular device to authenticate yourself, and you need to have it every time you authenticate yourself. If you lose it, you can't authenticate yourself, Period.

Luckily, it's always with you, so you can authenticate yourself. Since it's always with you, you can always use it to authenticate. Because you always use the device to authenticate yourself, you're always authenticating with a secret which you can't remember without writing it down – and because the device keeps the secret, neither you nor anyone else knows it.

Because the secret is this strong, it can't be recovered by guessing or by brute-force enumeration, as in a dictionary attack. This means that in order to get the secret and use it, your enemy has to get the device itself.

But if the enemy does get the device itself, you'll know immediately, because you notice quickly if you lose it.

And once you know the enemy has the device, you will of course take steps to cancel it and get another right away.

The overall effect here is to reduce the number of ways your authentication can be attacked, and to reduce the period of time during which the enemy can profit from a successful attack.

We need to get a strong authentication device into the hands of every man, woman, and child on the planet.

To do that, we’re going to need lots of strong authentication device providers and lots of innovation. The devices are going to need to be cheap, they're going to need to be trivially easy to use, and they're going to have to come in all shapes, sizes, and colors to fit with the widest possible variety of lifestyles.

If you want strong authentication in your cell phone, we need to give it to you in your cell phone. Want it in your iPod? We need to put it there. Wristwatch? Why not? Car key? Sure. Glass eye? Well, I don’t want to beta test that one, but we’ll - ahem - look into it.

Strong authentication devices aren’t a panacea. There are lots of problems they won’t solve. Bruce argues that they won’t even solve the phishing problem - and he’s right. But here’s what strong authentication will do:

1. It will shorten your window of vulnerability after your authenticator is stolen. Today, if someone phishes your password, or uses a password-cracking program to recover it, or looks over your shoulder while you type it into a login screen, you might not notice for a long time. During this long time, the password thief may do you a lot of harm. When you have a strong authentication device, you notice it’s missing the first time you go to use it, so you can report the loss and stop the damage.
2. It will force anybody who wants to hijack your authenticator without stealing it to interact with you every time he wants to use your identity. Today, a phisher who gets your password once can use it as often as he likes. Since a strong authentication device never does the same thing twice, the phisher who wants to use your identity has to get you to give him a one-time value, and then he has to use that value before it expires and before you use it. If he wants to use your identity again, he has to get back in touch with you to get a new one-time value. As Bruce notes, the phisher can do this using a man-in-the-middle attack, or he can plant a Trojan Horse on your client system. But both of those things are harder than sending you an email and waiting for you to respond, and both are things we can, and must, defend against in other ways.

If we’re going to use authentication at all, there’s no excuse for using weak authentication. Let’s fix the problem. We’ve got 4 years. We've also got a roadmap. The OATH consortium, which I've been participating in for the last two years, is dedicated to promoting the development and adoption of open, strong authentication technologies.

OATH isn't a standards body, and it doesn't make money off strong authentication. Instead, it encourages and publicizes. OATH has endorsed the development of an open, one-time password standard called HOTP at IETF. OATH has also published a reference architecture for strong authentication, and we're working on identifying the work that needs to be done to make that architecture a reality.

If you agree that we need to get rid of passwords and replace them with something better, I'd like you to do something about it.

If you can, I'd like you to help us advance the cause of the strong authentication by joining OATH.

If you don't feel that you have something to contribute, or if you're already working on something else equally important and don't have the time to join this crusade, you can still do something very important: you can ask the providers of your information systems and services this simple question:

"Why do I still have to use a password? It's annoying for me, it's expensive for you, and it's insecure for all of us – can't you give me something better?"

If you don't get an answer that makes sense, keep asking.