Interesting vulnerability (now patched) in Google’s 2-Factor Authentication model that allowed full account access.
Google was a front-runner in bringing 2FA to a consumer audience - although it continues to remain an opt-in only feature. ( This article gives a nice general overview of 2FA in other popular consumer services).
More interesting to me was that Google has seemingly bucked the oAuth trend made popular by other services (notably Twitter) with their implementation of *Application-Specific Passwords":
Generally, once you turn on 2-step verification, Google asks you to create a separate Application-Specific Password for each application you use (hence “Application-Specific”) that doesn’t support logins using 2-step verification. Then you use that ASP in place of your actual password. In more-concrete terms, you create ASPs for most client applications that don’t use a web-based login: email clients using IMAP and SMTP (Apple Mail, Thunderbird, etc.); chat clients communicating over XMPP (Adium, Pidgin, etc.), and calendar applications that sync using CalDAV (iCal, etc.).
As an iOS user and Google Apps user, ASPs have nearly forced me to turn off 2FA a number of times. The implementation forces users to navigate deep within their Google account settings to generate a 16-character code you would have to type onto a second screen (I encountered this most often with new apps seeking to sync with Gmail/Contacts/Calendars).
This caught my eye though:
Even some of Google’s own software initially required you to use ASPs – e.g. to enable Chrome’s sync features, or to set up your Google account on an Android device. More recently, these clients have generally shifted to using methods along the lines of OAuth. In this model, when you first log in using a new application or device, you get an authorization prompt — including 2-step verification — in a webview; after a successful login, Google’s service returns a limited-access “token”, which is used to authenticate your device/application in the future.
It’s a fine line between having an authentication standard that is so dumbed down that it is easy to circumvent versus complicated enough to foil moderately sophisticated hacking attempts. Google’s attempts to prevent account hijacking are clearly working, but it user authentication is still very much a disjointed process on mobile.
Ideally I’d like to see an evolved version of the Google Authenticator app that would allow me to authenticate a device once and then leverage ASP/oAuth integration in the app itself to allow one-touch authentication of a new app/service seeking access to my account.
Bonus points for instituting real-time notifications/tracking of account access attempts (American Express’s Passbook implementation of transaction notifications is the model here) for users to verify their accounts on the go.
Account security is an incredibly hard problem to solve technically, let alone for a consumer-oriented suite of services in use by a global audience. I think there are ways to effectively and securely combine both 2FA and something like oAuth/ASPs to prevent ever-evolving security threats while also presenting users with something that is simple enough to encourage broader adoption.
