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

61–70 of 75 posts

Re: Bypassing Google’s Two-Factor Authentication

#61

Post by drivebyacct2 »

eropple wrote: post #60
drivebyacct2 wrote: post #56

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.

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.

Re: Bypassing Google’s Two-Factor Authentication

#62

Post by trotsky »

xyzzyz wrote: post #25
wting wrote: post #24

Earlier quoted context omitted.

Multi-factor authentication means choosing from: 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 passwor…

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?

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.

Re: Bypassing Google’s Two-Factor Authentication

#64

Post by jessaustin »

stephengillie wrote: post #15
jgrahamc wrote: post #2

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

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.

Even so, you're probably right in the long term.

Re: Bypassing Google’s Two-Factor Authentication

#65

Post by chirayuk »

Sidnicious wrote: post #31
cryptoz wrote: post #19

Earlier quoted context omitted.

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

At least on iOS, the Google Authenticator app doesn't allow its tokens to be backed up or transferred.

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.

Re: Bypassing Google’s Two-Factor Authentication

#66

Post by cwb71 »

jessaustin wrote: post #64
stephengillie wrote: post #15

Earlier quoted context omitted.

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…

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.

Re: Bypassing Google’s Two-Factor Authentication

#67

Post by cwb71 »

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…

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.

Re: Bypassing Google’s Two-Factor Authentication

#68

Post by r00fus »

tannerc wrote: post #26
stephengillie wrote: post #15

Earlier quoted context omitted.

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?

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.

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

Re: Bypassing Google’s Two-Factor Authentication

#69

Post by sneak »

akgood wrote: post #49
sneak wrote: post #47

Earlier quoted context omitted.

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

The article says it's fixed.

Re: Bypassing Google’s Two-Factor Authentication

#70

Post by hackerboos »

inopinatus wrote: post #57
trotsky wrote: post #8

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 confess I was misled by the name "application specific" into assuming that such a binding already occurred.

That's "application specific" not machine specific. I'm not sure, other than IP address, how they could tell machines apart.
Post reply on HN