Hundreds of millions of people use passwords every day — they unlock our devices, email, social networking, and even bank accounts. However, passwords are an increasingly feeble way to protect ourselves: Barely a week goes by without a major security gaffe hitting the news. This week, it’s Cisco — maker of much of the hardware that essentially powers the Internet.
Right now, almost everyone is looking to move beyond passwords to multifactor authentication: requiring “something you have” or “something you are” in addition to something you know. Biometric technologies that measure eyes, fingerprints, faces, and/or voices are getting more practical, but frequently fail for some people, and are hard to bring to hundreds of millions of users.
Aren’t we overlooking the obvious? Isn’t the solution to multifactor security already in our pockets?
Believe it or not, Americans have been using multi-factor authentication for years whenever they do online banking — or, at least, watered-down versions of it. In 2001, the Federal Financial Institutions Examination Council (FFIEC) required U.S. online banking services roll out true multifactor authentication by 2006.
It’s 2013 and we’re still logging into online banking with passwords. What happened?
“Basically, banks lobbied,” said Rich Mogull, CEO and analyst at Securosis. “Biometrics and security tokens can work fine in isolation, but it’s very hard to scale them even to just banking. Consumers don’t want to deal with multiple things like that. Most people don’t even put passcodes on phones.”
So, banks pushed back. By 2005, the FFIEC issued updated guidelines that allowed banks to authenticate by password and “device identification” — basically, profiling users’ systems. If a customer signs in from a known device, they just need a password; otherwise, the customer needs to jump through more hoops — usually challenge questions. The idea is that profiling devices amounts to verifying something users have (a computer, smartphone, or tablet) to accompany the password they know.
Banks have become more sophisticated at identifying devices, and still-newer federal guidelines require banks use more than an easily copied browser cookie. But the system is still weak. Everything happens over a single channel, so if a bad actor can tap into a user’s connection (perhaps by theft, hacks, or malware), it’s all over. Further, anyone is treated like a customer using a new device — and as New York Times columnist David Pogue can attest, truthfully-answered security questions sometimes offer scant protection.
However, online banking’s limited form of multifactor security has big upside for consumers. For most users most of the time, device profiling is invisible and works just like a password — which almost everyone understands.
Digital tokens, security cards, and other devices have been used in multifactor authentication for decades. However, like biometrics, so far nothing has proven workable for millions of everyday people. There are also no widespread standards, so folks could need a dozen different fobs, tokens, USB sticks, and cards to access their favorite services. No one is going to do that.
So what about the phones in our pockets? Almost a year ago researchers found almost 90 percent of American adults owned mobile phones — almost half had smartphones. The numbers must be higher now: surely they be used for multifactor authentication?
That’s the idea behind Google’s two-step verification, which sends a one-time PIN code to a phone by SMS or voice when logging in to Google services. Users enter both their password and the code to log in. Of course, phones can be lost or stolen, and if the battery dies or no mobile service is available, users get locked out. But the service works even with feature phones, and is certainly more secure — if less convenient — than a password alone.
Google’s two-step verification gets more interesting with Google Authenticator, available for Android, iOS, and BlackBerry. Google Authenticator uses Time-based One-Time Passwords (TOTP), an standard backed by the Initiative for Open Authentication. Basically, the app contains an encrypted secret and generates a new six-digit code every 30 seconds. Users enter that code along with their password to prove they have the correct device. As long as the phone’s clock is correct, Google Authenticator works without phone service; what’s more, its 30-second codes work with other services that support TOTP: right now, that includes Dropbox, LastPass, and Amazon Web Services. Likewise, other apps that support TOTP can work with Google.
But there are issues. Users submit verification codes on the same channel as passwords, so they’re vulnerable to the same interception scenarios as online banking. Since TOTP apps contain a secret, anyone (anywhere in the world) could generate legitimate codes if the app or secret gets cracked. And no system’s perfect: Last month Google fixed a problem that could allow total account takeovers via app-specific passwords. Fun.
Where do we go from here?
The biggest problem with systems like Google two-step verification is simply that they’re a pain in the ass. Do you want fiddle with your phone and codes every single time you log in to a service? Do your parents, grandparents, friends, or children? Most people don’t. Even technophiles who love the cool factor (and the security) likely find the process awkward in only a few weeks.
Numbers suggest the pain is real. In January, Google supplied Wired’s Robert MacMillan a graph of two-step adoption, including a spike accompanying Mat Honan’s “Epic Hacking” article last August. Notice which axis has no labels? Google representatives declined to say how many people use its two-factor authentication, but Google security VP Eric Grosse told MacMillan a quarter million users enrolled after Honan’s article. By that metric, my back-of-the-envelope estimate is about 20 million people have signed up to date — barely a dent in 500+ million people Google claims have Google+ accounts. That figure seemed about right to a Google employee who didn’t want to be named: She estimated less than ten percent of “active” Google+ users had signed up. “And not all of them stick with it,” she noted.
“When you have an unbridled audience, you can’t assume any kind of behavior beyond the basics — especially if you haven’t given that audience a reason to want that behavior,” said Christian Hessler, CEO of mobile authentication company LiveEnsure. “There’s no way you’re going to train a billion people to do something they don’t want to do.”
LiveEnsure relies on users verifying out-of-band using their mobile device (or even via email). Enter just a username (or use a single sign-in service like Twitter or Facebook), and LiveEnsure leverages the user’s broader context to authenticate: no password required. Right now, LiveEnsure uses “line-of-sight” — users scan a QR code on screen using their phone to confirm their login — but other verification methods are coming soon. LiveEnsure sidesteps interception by using a separate connection to verification, but also doesn’t rely on shared secrets in browsers, devices, or even its service. If the system is cracked, LiveEnsure says the individual pieces have no value to an attacker.
“What’s in our database could be mailed out on CDs as a Christmas present, and it would be useless,” said Hessler. “No secrets go over the wire, the only transaction is a simple yes or no.”
LiveEnsure’s approach is easier then entering PINs, but still requires users fiddle with mobile devices and apps to log in. Others aim to make the process more transparent.
Toopher is leveraging mobile devices awareness of their location via GPS or Wi-Fi as a way to transparently authenticate users — at least, from pre-approved locations.
“Toopher is bringing more context to the authentication decision to make it invisible,” said founder and CTO Evan Grimm. “If a user is typically at home doing online banking, a user can automate it to make the decision invisible.”
Automation isn’t required: Users can confirm on their mobile device every time, if they like. But if users tell Toopher what’s normal, they only need to have their phone in their pocket and authentication happens transparently. Users just enter a password and everything else is invisible. If the device is at an unknown location, users need to confirm on their phone — and if there’s no connectivity, Toopher falls back to a time-based PIN using the same technology as Google Authenticator.
“Toopher doesn’t try to fundamentally change the user experience, said Grimm. “The problem with other multifactor solutions wasn’t that they didn’t add protection, but that they changed the user experience, and therefore had impediments to adoption.”
You have to be in the game
Passwords aren’t going away, but they’ll be augmented by locations, one-time PINs, line-of-sight and line-of-sound solutions, biometrics, or even information about nearby Bluetooth and Wi-Fi devices. Smartphones and mobile devices seem the most likely way to add more context for authentication.
Of course, you have to be in the game if you want to play. Not everybody has smartphones, and new authentication technology may exclude users without recent tech, leaving the rest of the world more vulnerable to hacks and identity theft. Digital security could easily become something that distinguishes haves from have-nots.
And, so far, there’s no telling what solutions will win out. Toopher and LiveEnsure are just two of many players, and they all face a chicken-and-egg problem: Without adoption by both users and services, they don’t help anybody. Toopher recently secured $2 million in startup funding; LiveEnsure is talking to some big names and hopes to emerge from stealth mode soon. But it’s too early to say where anyone will end up.
In the meantime, if a service you rely on offers any form of multifactor authentication — whether via SMS, a smartphone app, or even a phone call — give it serious consideration. It’s almost certainly better protection than a password alone … even if it’s also almost certainly a pain in the ass.
[Updated 24-Mar-2013 to clarify details on FFIEC and LiveEnsure, and correct a production error.]