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.
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 ;)
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.
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.
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...
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.
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.
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.
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?
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.
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.
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...
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.
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?
With Google's two-factor, logging in requires something you know (password) and something you have (phone). The 10 passwords should be locked somewhere physically safe as a fail-safe.
Two-factor authentication protects against password leaks and brute force password attacks.[0] It now takes two security failures to access your account rather than one.
On a side note, this is why secret questions are worthless as a security measure. Backing up a password with another mental fact is still single factor authentication.
[0]: Unless the attackers were able to attain your fail-safe passwords, but unlikely given the entropy and presumably Google's security.
I'm not talking about 10 passwords I have as a backup. I'm talking about 10 application specific password that are used every day by my phone, mail client, xmpp client etc. They just need to intercept any single of these password to compromise my mail account. How's this different from the situation before two-factor authentication?
You are confused by the misleading "application-specific password" terminology. These passwords each allow the same degree of access: the password you use on your phone could be interchanged with the one on your xmpp client. Aside from being able to revoke each independently, there's not much benefit from having many of them.
These are not equivalent to 2-factor auth (which grants you the benefits described in an earlier comment). App-specific passwords exist only to allow you, a 2-factor user, to use applications which do not yet support 2-factor auth.
The primary purpose is to reduce the impact of password reuse or the user interactively disclosing their password to an attacker. Primarily leaked password hashes and phishing attacks, but it also combats sslstrip style mitm attacks and keyloggers on public computers. Nobody is going around typing in ASPs.
It's not designed to mitigate your personal computer being compromised - the only solutions that can move the needle in that situation are far beyond anything normal folks are willing to put up with.
I think this is the answer, and I think it would have made sense if they'd called it a "device specific password" instead of an "application specific password".
I've got an asp (dsp?) for my phone (which all the applications that need one on my phone use), another for my iPad, another for each of my laptops, home computers, and my work computer. If I lose (or have stolen) my phone, I can revoke the password it knows - without needing to change any of my other devices.
Using the word "Application" allows everybody (including, I think, google's own security people) to make the incorrect assumption that the "iPhone mail password" is "specific" to mail - and only allows POP and IMAP to work. Instead, what "application" means is not the easily assumed "a piece of software" interpretation, but the "use to which something is put" interpretation. The decision and management of that "use to which a password is put" is not made nor emforced by Google, but is all up to _me_ (or, as it turned out, to any attacker who could lever one out of me).
Right. AFAICT, there's nothing inherently "specific" about the password at all, that name is mostly just a "serving suggesion" to the legitimate user (one which the attacker is free to ignore).
So calling it a "device specific password" doesn't make it any more sensible to me. I'd call it an "alternate weakest-link redundant password" to be precise, but Marketing rarely goes with my suggestions. :-)
Google does intentionally make it a little more difficult to do what you are doing by refusing to ever show you the password again once it has been generated. You have to store that "unmemorizable" sixteen letter password somewhere.
The workflow they seem to encourage is that an "application" asks for your password, you open a browser and generate a new ASP, then save it in that app and forget it forever.
By "application" they mean "something that asks for your password." Thunderbird or iChat, not IMAP or XMPP.
Your right, a password that only works for a specific service or property or protocol would help, but "email box" is not the best example of your point - even if the only Google access is could steal off you was the ability to read you mail, you've pretty much hosed - I can now go to every other website and ask them to send you a password reset, and you're now lost down the Mat Honan rabbit hole. Where does your appleID reset go? Or your domain registrar accounts? Your Facebook/Twitter/HN password reset email?
> I can now go to every other website and ask them to send you a password reset
Yes, and, provided I've discovered the issue in time, I can use one of my ten reset codes or OTP to log in, revoke/disable all my ASPs, and reset them again. Recoverable.
If you'd stolen my whole Google account, you've likely regenerated the codes and changed the backup email and phone number. No exit.
Sure, but that "provided I've discovered the issue in time" leaves a gaping hole for a sneaky attacker. If I've got your email password, and I'm camped on your email account while hitting all the other website's forgot password forms, and I delete all the mail as soon as I've retrieved the link - how do you "discover the issue"? In some ways, that sort of attack is even more insidious than taking over the Google account completely - at least being locked out of your account raises the big red flags immediately, how would you even notice I was reading all your mail with a stolen ASP? (While I'm being particularly evil in my thinking, I'm imagining an attacker quietly gaining access to read email, and not actively doing anything to arouse suspicion, then waiting for _you_ to hit passwrod reset links on various high-value-to-the-attacker sites, perhaps forcing that on you by triggering brute force protection on those other sites…)
They don't let you log in via the web, only via protocols that have a single field for "password", like xmpp, imap, and smtp. There is tons of data in the account which is not accessible with an ASP.
When you try to log in on the web with an ASP, it asks for the account password + OTP.
That's (probably) true right now, but the article points out that mis-using the chrome autologin mechanism allowed access to anything - including unfettered access to your account settings page - with just an ASP. This was true for at least 7 months. Until last Thursday, your xmpp ASP did give anyone with some specific knowledge access to all of what you think of as "data in the account which is not accessible with an ASP".
_Hopefully_ the fix in place now makes your statement correct now and in the future. But this shit is hard - I wouldn't be betting my house on it not having further flaws.
Constructive suggestion: create a new, non-obvious, high reliability email account. Don't use it for anything except as a password recovery email address for high importance accounts. I have my Google/Apple/Amazon/eBay/PayPal/DomainRegistrars/webhosting accounts pointed to it, but not things like Twitter/FaceBook/LinkedIn/forums/HN/n-random-website. Document carefully where you've used it so in the case of a high-profile intrusion on one of your "high importance" websites you know exactly where you need to change that email address (to prevent an attacker being able to leverage the disclosure of that email address). Don't ever publish that address anywhere else. I know this is mostly "security through obscurity", which is in crypto contexts a totally flawed proposition, but in terms of "reducing the attack surface" of your critical online accounts, I think it's an effective tactic.
No, ASPs can only be used to access account data available over imap, smtp, xmpp, and other non-web protocols that don't allow cookies/asking for the OTP.
The fix that Google rolled out blocks ASP-based logins from accessing a few highly-sensitive pages on https://accounts.google.com, but otherwise, little has changed. With a quick API request, you can still use an ASP to skip just about any other Google web-based login anywhere on the web. Google might have to completely eliminate their Chrome/Android auto-login feature to actually prevent this sort of thing...
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.
The main advantage is that people need to remember lower entropy passwords or can use the same password in multiple places without compromising two factor protected system. Also two factor auth protects against keyloggers.
Because the code is sent to a device Google know you have had physical possession of in the past. It's either sent by SMS, voice call, or to a pre-registered mobile app.
The general point of two factor authentication is that you need physical access to something (phone, token generator, etc), meaning that if somebody across the world knew your password they'd still be unable to cause any damage - or rather, it would take a lot more effort.
> Because the code is sent to a device Google know you have had physical possession of in the past. It's either sent by SMS, voice call, or to a pre-registered mobile app.
None of those connect to device you've had "physical possession in the past". Only the present. Phone calls, SMS and apps are all portable across hardware.
For TOTP, you can have the same account on more than one device (I do for convenience). All you need is the initial seed which you can either enter manually, or scan the barcode using more than one device.
If they know my master password, they also need to have a phone, that is correct. But if they know a single application specific password, they can read my mail just fine. How does the two-factor authentication protect me in this case?
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.
The really funny situation regarding the phone is that Google makes you do this when logging in on your phone too. So if you go buy a new phone, in order to log in you will have to undergo a few failed attempts, use their web log in form, which SMSs a password to the very same device you're using in the first place.
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.
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?
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.
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]
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.
> 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?
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.
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.
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.
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...
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.
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!?
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.
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.
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.
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.
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).
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.