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.


From: Melissa Frey

It seems to me that one should just buy an authenticator, and all companies should allowe you to link the authenticator to your account.  Once's its linked you only need one authenticator (they all have those crazy codes on the back.)  Perhaps instead of asking you to buy said authenticatory you pay a fee to use the one you have already.  That way you only need one token and use that token for authentication across multiple servers.

Melissa Frey

From: Jeff Schiller

I should mention that one of the things holding two-factor authentication back over the years has to do with vendors attempting to monetize them. It was (and for some vendors still) not unusual to find tokens sold for $50 each (!!) with an artificially limited lifetime so you had to keep buying them (including soft tokens where there isn't a battery to worry about). Not only does this raise cost, but it also raises the administrative cost of dealing with tokens because you have to worry about when each user's token will expire and getting them a new one in time. And, any stock of tokens you chose to keep on hand were "ticking!"


From: Leigh Klotz

Did you see the two-factor social attack last week?

From: Jeff Schiller

Sorry for the slow response...

I read that story. It was a highly targeted attack. Personally I don't believe that it shows a weakness in two-factor authentication. I believe it shows a weakness in the higher level authentication, namely how we prove who we truly are to the institutions we do business with. Consider that our ultimate authentication is a birth certificate and a utility bill!

I was originally going to say here that the use of SMS for code verification was a significant contributor, and it was. However if the executive instead depended on a hard token, the attackers probably could have gotten the bank to re-issue them a new token. This would likely have required a slightly different social attack, but I am sure it is still feasible.

So the lesson here, which is not a new lesson, is that higher value targets need better protection. This creates a bit of a conundrum for the banks. Because implementing stronger protection will likely add inconvenience to exactly those customers who they do not want to inconvenience!

From: Simon Leinen

It seems that some progress was made since this was written.  Google, Amazon (AWS) and Dropbox two-factor authentication now merrily live together in a single Google Authenticator instance on my phone.

From: Walt Houser

I am curious about your assessment of SQRL at 

The website's login presents a QR code containing the URL of its authentication service, plus a nonce. The user's smartphone signs the login URL using a private key derived from its master secret and the URL's domain name. The Smartphone sends the matching public key to identify the user, and the signature to authenticate it.

Copyright © 2009-2023 Jeffrey I. Schiller