Skip the navigation

Application-specific passwords weaken Google's two-factor authentication, researchers say

Researchers found a method to hijack Google accounts using application-specific passwords

By Lucian Constantin
February 26, 2013 08:25 AM ET

IDG News Service - Researchers from two-factor authentication provider Duo Security found a loophole in Google's authentication system that allowed them to bypass the company's 2-step login verification by abusing the unique passwords used to connect individual applications to Google accounts.

According to the Duo Security researchers, Google fixed the flaw on Feb. 21, but the incident highlights the fact that Google's application-specific passwords don't provide granular control over account data.

When enabled, Google's 2-step verification system requires the input of unique codes in addition to the account's regular password in order to log in. This is designed to prevent accounts from being hijacked even when the password is compromised. The unique codes can either be received at a phone number associated with the account or can be generated using a smartphone application.

However, 2-step verification only works when logging in through Google's site. In order to accommodate desktop e-mail clients, chat programs, calendar applications and so on, Google introduced the concept of application-specific passwords (ASPs). These are randomly-generated passwords that allow applications to access the account without the need of a second authentication factor. ASPs can be revoked at any time without changing the account's main password.

The problem is, "ASPs are -- in terms of enforcement -- not actually application-specific at all!" the Duo Security researchers said Monday in a blog post. "If you create an ASP for use in (for example) an XMPP chat client, that same ASP can also be used to read your email over IMAP, or grab your calendar events with CalDAV."

The researchers found a flaw in the auto-login mechanism implemented in Chrome in the latest versions of Android that allowed them to use an ASP to gain access to a Google account's recovery and 2-step verification settings.

In essence, the flaw could have allowed an attacker who stole an ASP for a Google account to change the mobile phone number and recovery email address associated with that account or even disable 2-step verification altogether.

"Given nothing but a username, an ASP, and a single request to https://android.clients.google.com/auth, we can log into any Google web property without any login prompt (or 2-step verification)!" the Duo Security researchers said. "This is no longer the case as of February 21st, when Google engineers pushed a fix to close this loophole."

In addition to fixing the issue, Google apparently also changed the message displayed after generating an application-specific password in order to warn users that "this password grants complete access to your Google Account."

"We think it's a rather significant hole in a strong authentication system if a user still has some form of 'password' that is sufficient to take over full control of his account," the Duo Security researchers said. "However, we're still confident that -- even before rolling out their fix -- enabling Google's 2-step verification was unequivocally better than not doing so."

That said, the researchers would like to see Google implement some kind of mechanism similar to OAuth tokens that would allow restricting the privileges of every individual application-specific password.

Google did not immediately respond to a request for comment about this flaw or possible plans to implement more granular control for application-specific passwords in the future.

Reprinted with permission from IDG.net. Story copyright 2014 International Data Group. All rights reserved.
Our Commenting Policies
Internet of Things: Get the latest!
Internet of Things

Our new bimonthly Internet of Things newsletter helps you keep pace with the rapidly evolving technologies, trends and developments related to the IoT. Subscribe now and stay up to date!