7 ms·

Bypassing Google’s Two-Factor Authentication

180 points by seanponeil 14y ago

KernelJay 14y ago
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/Hats-off-to-Google-for-breaking-my-app/ba-p/8106 http://connect.ncircle.com/t5/VERT-Security-Research-Blog/Ha...
jgrahamc 14y ago
Interesting read as bypassing the same thing was needed for this hack: http://blog.cloudflare.com/the-four-critical-security-flaws-that-resulte http://blog.cloudflare.com/the-four-critical-security-flaws-...
- stephengillie 14y ago
  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 14y ago
    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.
    - r00fus 14y ago
      Per-password permissions are basically the RBAC design pattern [1], which at it's core requires 3 tables with 2 N:N joins in a relational mapping structure (the wikipedia article lays out 4 classes/tables). That's a lot of complexity compared to a simple session-authenticated validation. [1] http://en.wikipedia.org/wiki/Role-based_access_control http://en.wikipedia.org/wiki/Role-based_access_control
    - akgood 14y ago
      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/ https://aws.amazon.com/iam/
  - jessaustin 14y ago
    This might be difficult to administer. Nobody smart stores users' passwords directly, so it's not like they can list different passwords with their associated permissions on a page. If you go with user-selected "nicknames", then do you require the app to use the nickname too? Or do you just compare with all the hashes on the user's account? Maybe instead the app has to pass a hash of the perms themselves, serialized in some canonical way. How many users can figure this out? I've known DBAs who couldn't figure out analogous situations. Even so, you're probably right in the long term.
    - cwb71 14y ago
      Google already requires that you name each ASP and provides a table listing the name, the date it was created, the date it was last used to log in, and a link to revoke it. They'd just need to add an option to modify those. The OAuth entries on the same page list each's entitlements, though you don't have the option to modify them.
SmileyKeith 14y ago
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 14y ago
  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 14y ago
    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.
eksith 14y ago
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.
grkvlt 14y ago
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-issue.html http://grkvlt.blogspot.co.uk/2012/08/google-tfa-security-iss...
- deleted 14y ago
  [deleted]
simon_weber 14y ago
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 https://github.com/simon-weber/Unofficial-Google-Music-API [1] http://nelenkov.blogspot.com/2012/11/sso-using-account-manager.html http://nelenkov.blogspot.com/2012/11/sso-using-account-manag...
Goopplesoft 14y ago
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 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 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).
trotsky 14y ago
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 14y ago
  I confess I was misled by the name "application specific" into assuming that such a binding already occurred.
  - hackerboos 14y ago
    That's "application specific" not machine specific. I'm not sure, other than IP address, how they could tell machines apart.
    - samwillis 14y ago
      Could they create a fingerprint of the application logging in using the request headers and user agent and watch for a grater than n% change in that fingerprint? Obviously a hacker could just copy the applications headers...
    - inopinatus 14y ago
      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.
6thSigma 14y ago
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 14y ago
  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 14y ago
    The loop hole seems to require the plain text ASP though.
- Zikes 14y ago
  Presumably the ASP could be intercepted via MITM, when it's being passed to the application for which it was generated.
xyzzyz 14y ago
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?
- grey-area 14y ago
  Could anyone explain to me what's the point of Google's two-factor authentication? Without application specific passwords it's actually pretty secure. With ASP of course, according to this article, it's no more secure at all. So it looks like ASPs need to be revised/locked down. That doesn't mean that 2-factor security is useless in principle, just that this facet of it is insecure.
  - badgar 14y ago
    > With ASP of course, according to this article, it's no more secure at all. This is not at all the conclusion of the article. This isn't a bright-line issue; security exists on a spectrum.
- Inufu 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - xyzzyz 14y ago
    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.
- 14y ago
sbronstein 14y ago
> 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 14y ago
  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 14y ago
    Yeah after re-reading I think you are correct. And yes, I certainly agree that it was a real vulnerability!
JumpCrisscross 14y ago
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.
JangoSteve 14y ago
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 14y ago
  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.
dpeck 14y ago
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.
martinced 14y ago
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 14y ago
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.
- trotsky 14y ago
  I think you must be on a testing channel - it's still a hard to find flag that defaults to off on stable, and it wasn't more than a few months ago that it sat broken for weeks and finally got yanked for a time. also - 3rd party mailers and xmpp clients.
- eropple 14y ago
  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 14y ago
    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.
hakaaaaak 14y ago
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.

180 points by seanponeil 14y ago

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/Hats-off-to-Google-for-breaking-my-app/ba-p/8106 http://connect.ncircle.com/t5/VERT-Security-Research-Blog/Ha...

jgrahamc 14y ago

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

stephengillie 14y ago
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 14y ago
  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.
  - r00fus 14y ago
    Per-password permissions are basically the RBAC design pattern [1], which at it's core requires 3 tables with 2 N:N joins in a relational mapping structure (the wikipedia article lays out 4 classes/tables). That's a lot of complexity compared to a simple session-authenticated validation. [1] http://en.wikipedia.org/wiki/Role-based_access_control http://en.wikipedia.org/wiki/Role-based_access_control
  - akgood 14y ago
    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/ https://aws.amazon.com/iam/
- jessaustin 14y ago
  This might be difficult to administer. Nobody smart stores users' passwords directly, so it's not like they can list different passwords with their associated permissions on a page. If you go with user-selected "nicknames", then do you require the app to use the nickname too? Or do you just compare with all the hashes on the user's account? Maybe instead the app has to pass a hash of the perms themselves, serialized in some canonical way. How many users can figure this out? I've known DBAs who couldn't figure out analogous situations. Even so, you're probably right in the long term.
  - cwb71 14y ago
    Google already requires that you name each ASP and provides a table listing the name, the date it was created, the date it was last used to log in, and a link to revoke it. They'd just need to add an option to modify those. The OAuth entries on the same page list each's entitlements, though you don't have the option to modify them.

SmileyKeith 14y ago

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 14y ago
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 14y ago
  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.

eksith 14y ago

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.

grkvlt 14y ago

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-issue.html http://grkvlt.blogspot.co.uk/2012/08/google-tfa-security-iss...

deleted 14y ago
[deleted]

simon_weber 14y ago

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 https://github.com/simon-weber/Unofficial-Google-Music-API [1] http://nelenkov.blogspot.com/2012/11/sso-using-account-manager.html http://nelenkov.blogspot.com/2012/11/sso-using-account-manag...

Goopplesoft 14y ago

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

trotsky 14y ago

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 14y ago
I confess I was misled by the name "application specific" into assuming that such a binding already occurred.
- hackerboos 14y ago
  That's "application specific" not machine specific. I'm not sure, other than IP address, how they could tell machines apart.
  - samwillis 14y ago
    Could they create a fingerprint of the application logging in using the request headers and user agent and watch for a grater than n% change in that fingerprint? Obviously a hacker could just copy the applications headers...
  - inopinatus 14y ago
    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.

6thSigma 14y ago

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 14y ago
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 14y ago
  The loop hole seems to require the plain text ASP though.
Zikes 14y ago
Presumably the ASP could be intercepted via MITM, when it's being passed to the application for which it was generated.

xyzzyz 14y ago

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?

grey-area 14y ago
Could anyone explain to me what's the point of Google's two-factor authentication? Without application specific passwords it's actually pretty secure. With ASP of course, according to this article, it's no more secure at all. So it looks like ASPs need to be revised/locked down. That doesn't mean that 2-factor security is useless in principle, just that this facet of it is insecure.
- badgar 14y ago
  > With ASP of course, according to this article, it's no more secure at all. This is not at all the conclusion of the article. This isn't a bright-line issue; security exists on a spectrum.
Inufu 14y ago
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.
- deleted 14y ago
  [deleted]
- xyzzyz 14y ago
  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.
14y ago

sbronstein 14y ago

> 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 14y ago
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 14y ago
  Yeah after re-reading I think you are correct. And yes, I certainly agree that it was a real vulnerability!

JumpCrisscross 14y ago

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.

JangoSteve 14y ago

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 14y ago
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.

dpeck 14y ago

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.

martinced 14y ago

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 14y ago

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.

trotsky 14y ago
I think you must be on a testing channel - it's still a hard to find flag that defaults to off on stable, and it wasn't more than a few months ago that it sat broken for weeks and finally got yanked for a time. also - 3rd party mailers and xmpp clients.
eropple 14y ago
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 14y ago
  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.

hakaaaaak 14y ago

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.