

Bypassing Google’s Two-Factor Authentication - seanponeil
https://blog.duosecurity.com/2013/02/bypassing-googles-two-factor-authentication/

======
JangoSteve
The most interesting and clarifying takeaway for me was the revelation that
with 2-factor auth enabled (which I've had for some time now), the Application
Specific Passwords were actually _more_ privileged than my actual account
password, considering my account password required a second factor of
authentication to work, assuming my device wasn't "remembered for 30 days".

The thing that's always annoyed me is the way that Google allows ASPs in some
places but not in others, particularly when an application uses OAuth.
Consider this:

A 3rd-party app uses OAuth to access your Google account. Great!

You install the app, fire it up, and the first thing the app does is prompts
you to authenticate the app. It takes you to Google's OAuth screen to approve
the app. This often happens within a popup window in the app, not your actual
browser, which means you're not logged into your Google account, so the first
thing you're presented with is a Google login form.

Now, this is a popup window with no URL visible, so how do I know that this is
actually Google's form on their server? And even if it is, how do I know the
app isn't using some embedded JavaScript to sniff my credentials?

Not wanting to take a chance, I head over to my browser and create a new
application-specific password to enter into the login form, knowing that I
could easily revoke it if I change my mind. I enter the ASP in the app's popup
Google login form, and lo and behold I'm greeted with the message "Please
enter your account password and not an Application Specific Password here."

Turns out Google returns a message when you're using an application-specific
password prompting you to enter your actual password. Now they've set that
precedent. Now any app can simply code up a form to look like Googles, throw
it in a popup, and put that message in there after the first time you submit
the form to make sure they get your account password (of course, doesn't
matter for me, because they don't have my second factor, but it would matter
for the majority of people, who don't have 2-factor auth setup). If you didn't
enter an ASP the first time, you'd just assume you mistyped or mis-pasted your
actual password the first time, and enter it again the second time. Now they
can be sure they have your actual password.

Of course, all this would have been moot if the ASP was more powerful than the
actual password to begin with, but it seems like after Google's fix, this is
back to being a problem.

~~~
trotsky
Once you've downloaded and installed a native application and plan to grant it
access to your google account you've decided you trust the application. If you
install a malicious app and give it credentials it can fuck you about 50
different ways, even if there is a url bar indicating you're on a google.com
server.

Any app that takes a ASP would otherwise be storing your main account
password. Two step is still improving your security posture here - your main
credential can't be used without the temporal pin so the ASP is actually much
more valuable.

If you're still concerned about a native popup, just don't enter your correct
password the first time. If it fails you're probably pretty safe - Phishing
style credential captures usually won't pass it through and risk server side
anomaly detection.

------
JumpCrisscross
I had this vulnerability cast into sharp relief recently through my Apple ID
compromising my contacts. I sync my Gmail and Gmail contacts via IMAP to my
iPhone and iPad using application-specific passwords. Both devices are backed
up on iCloud. When my Apple ID was compromised the crook restored my iCloud
backup to a new device, complete, to my horror, with the application specific
passwords, which were used to stream out my contacts.

New devices and novel data requests do not revoke application-specific
passwords which, as the article notes, are anything but specific. Also,
Apple's security support is a 24-hour round-trip via an email technician.

------
grkvlt
I reported this to Google about the same time, in June last year, and got a
similar response. Interestingly, I published some notes on the issue almost
exactly one week before the duosecurity researchers 'discovered' it ;)

[http://grkvlt.blogspot.co.uk/2012/08/google-tfa-security-
iss...](http://grkvlt.blogspot.co.uk/2012/08/google-tfa-security-issue.html)

------
trotsky
As an early google two step user, i've often wished those application specific
passwords would bind to the first property that they're used for. From what I
understand their current layered service architectures for some products makes
this difficult for them to pull off.

For better or worse, google two step authentication is primarily to mitigate
shared passwords, phishing and kiosk style keyloggers.

~~~
inopinatus
I confess I was misled by the name "application specific" into assuming that
such a binding already occurred.

~~~
hackerboos
That's "application specific" not machine specific. I'm not sure, other than
IP address, how they could tell machines apart.

~~~
inopinatus
I don't need them to be machine specific. What I expected was that a password
issued (and immediately used) for e.g. authenticating to Gmail's IMAP service
is then disqualified authorisation for any other Google service.

------
eksith
The problem doesn't seem to be the ASP itself, but the failed (OAuth-like?)
implementation.

"- OAuth tokens are created automatically, while ASPs are a thoroughly manual
affair"

"- OAuth tokens use a flexible authorization model, and can be restricted to
accessing only certain data or services in your account. By contrast, ASPs are
— in terms of enforcement — not actually application-specific at all!"

Well, there's your problem. Application _Specific_ Password isn't very
specific at all.

------
jgrahamc
Interesting read as bypassing the same thing was needed for this hack:
[http://blog.cloudflare.com/the-four-critical-security-
flaws-...](http://blog.cloudflare.com/the-four-critical-security-flaws-that-
resulte)

~~~
stephengillie
I said it then, I'll say it again -- The solution is obvious: allow per-
password permissions.

For instance, if I make an app-specific password to sync my bookmarks, that
password shouldn't provide access to my Gmail or my settings. Why isn't this
already a feature?

~~~
tannerc
What are possible reasons per-password permissions hasn't been a feature
implemented by major websites yet?

Is it simply that the way they do it now is easier to create/manage?

Seems like a no-brainer.

~~~
akgood
The AWS Identity and Access Management (IAM) system [1] is perhaps the most
comprehensive RBAC deployment I've encountered in a web-based service. It's
extremely powerful, extremely flexible, and rather hard to use. AWS is a
service designed (primarily) for developer-types, so if they roll out
something that requires users to have a relatively strong understanding of
security concepts (and to expend some thought and effort to get things right),
that's arguably OK.

Google is a different story. People commenting on this thread would appreciate
some in-depth manual controls over the resources each Google credential can
access, but making this sort of thing accessible/understandable to an average
user is a formidable challenge.

They might be able to get part of the way there using a something like a TOFU
(Trust on First Use) policy - e.g. after you create an ASP and use it to login
over XMPP, that ASP would only be usable for XMPP logins for the remainder of
its existence. However, this might still confuse some users or break some
assumptions here and there (e.g. what if you have a client application that's
designed to do both email and chat?)

Besides all this, I wouldn't be surprised if Google would have to do some
major backend re-architecting for this sort of thing to even be possible...

[1] <https://aws.amazon.com/iam/>

------
xyzzyz
Could anyone explain to me what's the point of Google's two-factor
authentication? I mean, before that, I used to have one password I had to
guard carefully, and now I have ten passwords I have to guard carefully, and
the one I enter most often requires me to additionally type some digits I have
to read from my smartphone? What plausible attack scenario does two-factor
authentication protect me from?

~~~
Inufu
If I want to hack your account, it's not enough to steal your password, I also
need to steal your smartphone to generate the tokens.

edit: I was referring to the Google Authenticator App, not sending the codes
over SMS. That's imho less secure.

~~~
xyzzyz
You don't have to steal a master password. It's enough to steal an application
specific password, and if you do that, you won't need a smartphone to read my
mail.

------
SmileyKeith
I enabled this at some point in time, it's amazing how many services I use
that rely on Google. After I got over 20 application specific passwords, which
I guess are tell alls, I decided it wasn't worth the complication. The real
problem with this was apps implementations of the two-factor auth. I haven't
looked at any of the APIs (I know they don't exist for some services like
Reader) but if the entirety of the auth was only typing in a code sent to your
phone I would've stuck with it. It's when you get into these application
specific passwords, especially when you have to create new ones on your phone,
that I think it's more trouble than it's worth.

~~~
tiziano88
I'm not sure I follow, what services you are talking about that rely on
Google? I only had to generate a few ASPs for my email clients, and little
more. I use most of the Google-provided apps on Android though, so I never
have to actually log in to my Google account from my phone/tablet, it might be
the case that on iOS the situation is different?

~~~
SmileyKeith
I'm sorry I said that strangely. The point I was trying to get across that you
use Google logins a lot. For example I have 4 email accounts on 4 or 5
devices, in multiple mail applications along with service specific apps like
the Google plus or similar apps. Which ends up with a lot of application
specific passwords.

------
simon_weber
Google's authentication schemes can be incredibly confusing, and they're
something I've had to deal with while building an unofficial client to Google
Music [0].

Here are two things worth knowing (that are somewhat covered by the article):

* aside from OAuth, any method of client auth is basically equivalent to SSO (ie, your entire Google account). As noted in the article, this includes app-specific passwords

* SSO is not meant for programmatic access. If you want code to have access to SSO credentials, it's easiest to use some other auth service, and then "upgrade" to SSO (the linked blog post describes one way of doing this) [1]

[0] <https://github.com/simon-weber/Unofficial-Google-Music-API>

[1] [http://nelenkov.blogspot.com/2012/11/sso-using-account-
manag...](http://nelenkov.blogspot.com/2012/11/sso-using-account-manager.html)

------
dpeck
Realizing its a usability nightmare, these things really should be able to be
tied to a service. ASP for email, bind to smtp and imap, nothing else. ASP for
chat, only works with xmpp, etc.

------
sbronstein
> 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.

I don't really understand this sentence...they say that Google (post-fix) no
longer enables access to security-specific pages unless you do two factor
auth, so doesn't that mean that post-fix you _cannot_ fully take over
someone's Google account without two factor auth?

~~~
marshray
I think the "still" was meant to refer to "after the addition of the 2nd
factor to the auth process" rather than "after the fix to the vulnerability
described here".

It's making the case that this does represent a "real" vulnerability, even if
certain aspects of the behavior were understood and expected by the system
designers.

~~~
sbronstein
Yeah after re-reading I think you are correct. And yes, I certainly agree that
it was a real vulnerability!

------
6thSigma
So the security risk requires someone to somehow get your ASP? Correct me if
I'm wrong, but I believe you can only make a new ASP when you are already
signed in and it disappears after you 'hide' it or leave the page. It kind of
seems like if you can get a user's ASP, the account is probably already
compromised.

It's nice that they are fixing a couple loopholes, but not sure if it will
actually help any.

~~~
Shank
The main issue with this is the automatic login functionality. If a person has
2 factor enabled on their account, and any of their devices (phones, tablets,
etc) are stolen, it becomes trivial to act without a password to steal the
entire account. If they have a lock screen password, it becomes harder to
attack, but any compromised device would likely give an attacker a few hours
prior to a user noticing and killing its tokens.

~~~
6thSigma
The loop hole seems to require the plain text ASP though.

------
KernelJay
FYI - I had also observed some similar issues which I recently presented at a
security conference. (The conference talk happened to be the impetus for
Google to fix this stuff when they did.) For my perspective on the issues,
please check out my conference slides: [http://connect.ncircle.com/t5/VERT-
Security-Research-Blog/Ha...](http://connect.ncircle.com/t5/VERT-Security-
Research-Blog/Hats-off-to-Google-for-breaking-my-app/ba-p/8106)

------
hakaaaaak
At some point I'm going to give up using what everyone else uses. That will
solve this problem once and for all, because no one will know or probably care
what I'm using.

------
martinced
Apparently nobody mentioned it yet but TFA talks about the "timeline" and ends
up saying that, two days before publicly reporting, Google did change
something (after all, after saying for 6 months that the exploit was an
expected behavior):

 _"2013/02/21: Fix is pushed by Google to prevent ASP-initiated sessions from
accessing sensitive account interfaces."_

So is that one particular hole describe in the article / blog fixed or not!?

------
drivebyacct2
What are you guys doing with all of these ASPs? I used to need them but I
don't have _any_ ASPs registered on my TFA setup right now. Chrome and Android
both support the TFA flow now and have for a while.

~~~
eropple
A number of applications still don't. I have three ASPs for Pidgin and Adium
on different devices, one for Reeder on my Mac, one for Beejive on my iPad,
etc. Also, Chromium on my Linux netbook doesn't seem to support TFA, either.

~~~
drivebyacct2
Weird, maybe I did something to make mine use ASP or maybe it's only on
Dev/Beta channels? I did pretty much space on XMPP, I tend to just use IRC
these days.

------
Goopplesoft
I made a hosted api solution for easy two-factor/google authenticator (similar
to what lastpass and stripe are using) integration here
<https://www.gauthify.com> Its designed to integrate into the google
authenticator app since many big players are already using it (SMS & Email
option too).

With that aside I want to make it clear that the ASP aspect of Google
Authenticator was bypassed and RFC 6238 (<http://tools.ietf.org/html/rfc6238>)
timecode based two-factor authentication is still as solid as they were when
it was written (I had a false sense of urgency to read this when I read the
title).

