Bypassing Google’s Two-Factor Authentication(blog.duosecurity.com) |
Bypassing Google’s Two-Factor Authentication(blog.duosecurity.com) |
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.
http://grkvlt.blogspot.co.uk/2012/08/google-tfa-security-iss...
For better or worse, google two step authentication is primarily to mitigate shared passwords, phishing and kiosk style keyloggers.
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.
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.
"- 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.
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?
Even so, you're probably right in the long term.
Is it simply that the way they do it now is easier to create/manage?
Seems like a no-brainer.
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...
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?
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.
It's nice that they are fixing a couple loopholes, but not sure if it will actually help any.
"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!?
also - 3rd party mailers and xmpp clients.
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).
1. something you know (password)
2. something you have (phone, yubikey)
3. something you are (biometrics)
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.
edit: I was referring to the Google Authenticator App, not sending the codes over SMS. That's imho less secure.
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.
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.
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.
This is not at all the conclusion of the article. This isn't a bright-line issue; security exists on a spectrum.
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.
Obviously a hacker could just copy the applications headers...
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...
That's a lot of complexity compared to a simple session-authenticated validation.
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.
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'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).
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. :-)
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.
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.
When you try to log in on the web with an ASP, it asks for the account password + OTP.
_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.