Jeffrey I. Schiller
Networking, Security and Cavies

Passwords MUST Go!

Its really past time for the password to be a thing of the past. They are easy to guess, easy to steal and easy to phish for. People also love to use the same password on too many sites and applications. So if a password is stolen from one site, it can be used to abuse another.

Even at companies that make their business around computer security, like HBGary, staff used the same password for multiple systems so when one was compromised, so were the others.

But lets talk about some technical details. Why are passwords so bad. Well the first problem is they are what I call a "disclosing" authentication system. When you use a password you are "authenticating" yourself. You are proving to the site or application you are using that you are well... you!

Passwords are "disclosing" because when you use them, you provide the remote site not only proof of who you are, but you are also giving them to ability to impersonate you. You are your password, and now they have it too. And so does anyone who can monitor your communication.

Now the traditional approach to protecting communication is the encrypt it. Technologies such as SSL do a fine job at this. However there are plenty of other places where your communications can be intercepted besides the network, starting with your own computer! It is quite common for "malware" to grab characters from your keyboard and forward them to the attackers. Things get worse when you use a kiosk computer at locations such as airports and hotels. Everything you type into these computers is likely being reviewed by hostile parties.

Then there is the remote site itself. It has to store your password. The traditional protection at the remote site is to hash your password. However this is proving to be much less protection then thought. If your password isn't very complex, it is likely susceptible to a "rainbow" table attack. Basically the attackers have a mapping dictionary that contains tons of passwords and what they hash to. So they can take your hashed password and find the original password that maps to it. Of course if the attackers are reading out the password database, the remote site is already compromised, so how is getting your password make it any worse? Well, do you use that password anywhere else.

That people use the same password in multiple contexts is also insidious because there is no way for an administrator at one site to prevent password sharing, or even to know about it. So a compromise at one site may well have an impact at another site.

So what is the solution? Well there are several. They all fall under the rubric of "two-factor" authentication. One factor is your password (something you know) and the other factor is something you have (say your computer, or a key fob, or your phone).

X.509 client certificates (and SSH keys [if you don't know what these are, don't worry]) are one solution. But a more practical solution is a simple "one time password" token. These have been around for years. However they have been proprietary (and patented), expensive and inconvenient. But that is changing. Back in 2005 the IETF published RFC4226. This RFC defines an open standard for computing a simple numeric code that changes over time. The idea is that when you login, you provide your name, your password and then this (typically six numeric digits) code. It doesn't matter if an attacker steals the code, because it will change in 30 seconds, and they won't know what the new code will be.

You can now get standards based tokens from several vendors, and perhaps more interesting, you can get "soft tokens" which are applications you install on your mobile smartphone.

Google recently rolled out two-factor authentication as an option for Gmail and Google Apps, FOR ALL USERS. I strongly recommend that if you have a Google account, you look into this. Google has done a particularly good job here. Keep in mind, the last thing Google wants is for people to have to require support (there are many more Google customers then employees!). So Google is providing a pretty fail safe system. You can use your smartphone to generate one-time codes. You can have Google send it to you as a text message (which works even if you don't have the smartest phone that can run a soft token). You can even have Google call you and speak the code to you. You can configure a backup phone and finally when you setup your account, you get 10 pre-generated "backup" codes that you can print and store in a safe place if your phones all become unavailable.

One last and important point. Google has rolled this out in an "open" manner. You can use Google's authenticator smart phone application, or any soft token that is RFC4226 (TOTP) compliant. Other companies that have introduced two-factor authentication typically require you to obtain (or purchase) a token from them. So if you have many accounts that you want to have two-factor protection for, you wind up with a pocket full of tokens or a phone full of different token apps. EVEN WHEN THEY USE THE RFC4226 ALGORITHM. This is because they do not let you know a critical piece of information called the token seed (which is used to compute the one time passwords). Now some will argue that disclosing the token seed (which you only need to deal with when initializing or provisioning the token) you reduce your security because an attacker might be able to steal the seed. However this has to be traded off against the impracticality of expecting people to carry a pocket full of tokens. They won't.

Comments: