Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypassing Google’s Two-Factor Authentication

blog.duosecurity.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Bypassing Google’s Two-Factor Authentication

#41

Post by bigiain »

marshray wrote: post #27
xyzzyz wrote: post #25

Earlier quoted context omitted.

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?

All I can figure is it makes it easier to revoke one password without changing all the others.

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

Re: Bypassing Google’s Two-Factor Authentication

#42

Post by bigiain »

sneak wrote: post #33
xyzzyz wrote: post #25

Earlier quoted context omitted.

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?

Accessing your email box is a different matter than taking over the whole account. The former you can generally recover from.

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?

Re: Bypassing Google’s Two-Factor Authentication

#43

Post by 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.

Re: Bypassing Google’s Two-Factor Authentication

#44

Post by badgar »

grey-area wrote: post #35
xyzzyz wrote: post #12

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?

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.

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

Re: Bypassing Google’s Two-Factor Authentication

#45

Post by sneak »

rdl wrote: post #40
sneak wrote: post #33

Earlier quoted context omitted.

Accessing your email box is a different matter than taking over the whole account. The former you can generally recover from.

The Google "Application Specific Passwords" are actually complete passwords which give you access to all data in the account, which is the problem.

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.

Re: Bypassing Google’s Two-Factor Authentication

#46

Post by sneak »

bigiain wrote: post #42
sneak wrote: post #33

Earlier quoted context omitted.

Accessing your email box is a different matter than taking over the whole account. The former you can generally recover from.

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 appl…

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

Re: Bypassing Google’s Two-Factor Authentication

#47

Post by sneak »

Tyr42 wrote: post #39
sneak wrote: post #33

Earlier quoted context omitted.

Accessing your email box is a different matter than taking over the whole account. The former you can generally recover from.

That's the problem though, isn't it? They don't do password specific permissions, so any leak escalates up to taking over the whole account.

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.

Re: Bypassing Google’s Two-Factor Authentication

#48

Post by marshray »

bigiain wrote: post #41
marshray wrote: post #27

Earlier quoted context omitted.

All I can figure is it makes it easier to revoke one password without changing all the others.

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…

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

Re: Bypassing Google’s Two-Factor Authentication

#49

Post by akgood »

sneak wrote: post #47
Tyr42 wrote: post #39

Earlier quoted context omitted.

That's the problem though, isn't it? They don't do password specific permissions, so any leak escalates up to taking over the whole account.

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.

Not true. Read the article :)

Re: Bypassing Google’s Two-Factor Authentication

#50

Post by bigiain »

sneak wrote: post #46
bigiain wrote: post #42

Earlier quoted context omitted.

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 appl…

> 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…)
Post reply on HN