Is Authenticator part of the Google Panopticon?
September 6, 2013 10:01 AM Subscribe
Does third-party use of Google Authenticator go through the Google panopticon? If I use Google Authenticator on a third-party site, will that interaction send information back to Google, thereby informing Google of what I'm doing?
I just discovered that my company's web host uses Google Authenticator to implement two-factor authentication. While I'm a big fan of two-factor authentication, I want to resist Google's efforts to track every action of every human being on the planet.
I read the description of Google Authenticator on Wikipedia. That description makes it sound like G.A. is a specification and not an implementation. This implies that it could be implemented without involving Google at all.
Setting theory aside, how does it work in practice? I would be using the iPhone client (once it is back in the App Store, of course). If I start using G.A., will Google central command keep track of all the services I use it for, and all of my interactions with it? Will I start seeing adwords for plush underwear at home because I authenticated a plush underwear service at work?
I just discovered that my company's web host uses Google Authenticator to implement two-factor authentication. While I'm a big fan of two-factor authentication, I want to resist Google's efforts to track every action of every human being on the planet.
I read the description of Google Authenticator on Wikipedia. That description makes it sound like G.A. is a specification and not an implementation. This implies that it could be implemented without involving Google at all.
Setting theory aside, how does it work in practice? I would be using the iPhone client (once it is back in the App Store, of course). If I start using G.A., will Google central command keep track of all the services I use it for, and all of my interactions with it? Will I start seeing adwords for plush underwear at home because I authenticated a plush underwear service at work?
So the Authenticator app on Android has full permissions to send & receive data over the internet. iOS doesn't do fine-grained permissions, but it's pretty safe to assume it's the same. The legit use is doing time correction for time-based OTP codes. But in theory it could be doing anything.
That said, Authenticator doesn't connect with either your browser cookies directly nor does it have any knowledge of your Google account directly. On Android it knows which accounts are configured on the phone but it doesn't actually access any data from them that I'm aware of. Even Android app permissions are not quite that fine grained - the android app can create accounts, find accounts on the device and use accounts on the device which again has a legit use as a lot of people use Google Authenticator for 2-factor authentication logging into their Google accounts.
It's too bad that the Play store doesn't show app permissions in their Web UI but if you have the app installed on Android or try to install it you'll see what permissions it requests.
As for ad targeting, I have some knowledge of how AdSense and AdX do ad targeting and again, as far as I'm aware, authenticator activity is not one of the things used for ad targeting. You can see the cookie-based info used for ad targeting at https://www.google.com/settings/ads. In addition to that Google uses geolocation, time of day and a bunch of non-personal information for ad targeting. Third parties bidding through AdX may use their own info from other cookies or retargeting lists (AdWords uses retargeting as well).
So I doubt there's a definitive way to answer your question without a full audit of all the network activity happening when you run Authenticator but as far as I'm aware it's a standalone app that only ties into Google's identity system for the purposes of authentication.
posted by GuyZero at 10:26 AM on September 6, 2013
That said, Authenticator doesn't connect with either your browser cookies directly nor does it have any knowledge of your Google account directly. On Android it knows which accounts are configured on the phone but it doesn't actually access any data from them that I'm aware of. Even Android app permissions are not quite that fine grained - the android app can create accounts, find accounts on the device and use accounts on the device which again has a legit use as a lot of people use Google Authenticator for 2-factor authentication logging into their Google accounts.
It's too bad that the Play store doesn't show app permissions in their Web UI but if you have the app installed on Android or try to install it you'll see what permissions it requests.
As for ad targeting, I have some knowledge of how AdSense and AdX do ad targeting and again, as far as I'm aware, authenticator activity is not one of the things used for ad targeting. You can see the cookie-based info used for ad targeting at https://www.google.com/settings/ads. In addition to that Google uses geolocation, time of day and a bunch of non-personal information for ad targeting. Third parties bidding through AdX may use their own info from other cookies or retargeting lists (AdWords uses retargeting as well).
So I doubt there's a definitive way to answer your question without a full audit of all the network activity happening when you run Authenticator but as far as I'm aware it's a standalone app that only ties into Google's identity system for the purposes of authentication.
posted by GuyZero at 10:26 AM on September 6, 2013
FYI, you can even install your own Google Authenticator module in Linux.
Maybe this will ease your mind that Google isn't watching your auth codes:
http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/
posted by jozxyqk at 10:35 AM on September 6, 2013
Maybe this will ease your mind that Google isn't watching your auth codes:
http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/
posted by jozxyqk at 10:35 AM on September 6, 2013
Response by poster: Okay, so reading between the lines of what's said above, it sounds like the authentication process (including the original creation of the keys) just requires communication between my device and the service provider; Google servers don't of necessity get pulled into that process to create keys or look anything up or anything.
Now, if the software on my device was written by Google (e.g. the Google Authenticator iOS or Android app), then it's possible that software does communicate with Google Central Command, but so far the consensus from what I'm seeing above is that that's unlikely.
Thanks for the info. If anyone has anything else to add, please do.
posted by alms at 10:56 AM on September 6, 2013
Now, if the software on my device was written by Google (e.g. the Google Authenticator iOS or Android app), then it's possible that software does communicate with Google Central Command, but so far the consensus from what I'm seeing above is that that's unlikely.
Thanks for the info. If anyone has anything else to add, please do.
posted by alms at 10:56 AM on September 6, 2013
The Authenticator app is open source and nobody has found any backdoors or side channels yet.
Of course, on iOS you can't build it from the source code and run it yourself without a developer account; you have to trust that the version on the app store was actually built from that source. But that's Apple's fault, not Google's.
posted by teraflop at 11:10 AM on September 6, 2013 [2 favorites]
Of course, on iOS you can't build it from the source code and run it yourself without a developer account; you have to trust that the version on the app store was actually built from that source. But that's Apple's fault, not Google's.
posted by teraflop at 11:10 AM on September 6, 2013 [2 favorites]
Okay, so reading between the lines of what's said above, it sounds like the authentication process (including the original creation of the keys) just requires communication between my device and the service provider; Google servers don't of necessity get pulled into that process to create keys or look anything up or anything.
Technically, there's not even any authentication or communication going on. Your application creates the key and you either type the key into GA or scan a QR code of the key, and GA then uses that as the basis for the codes it generates. From GA's perspective, it has no idea what application a key is for (aside from the arbitrary name used to store it in GA); it just knows: I have a key, I'm making some codes based on it.
posted by The Michael The at 11:28 AM on September 6, 2013 [1 favorite]
Technically, there's not even any authentication or communication going on. Your application creates the key and you either type the key into GA or scan a QR code of the key, and GA then uses that as the basis for the codes it generates. From GA's perspective, it has no idea what application a key is for (aside from the arbitrary name used to store it in GA); it just knows: I have a key, I'm making some codes based on it.
posted by The Michael The at 11:28 AM on September 6, 2013 [1 favorite]
The code you get is essentially a function of the secret and the time (if a time based code) or the last code (if a count based code). There isn't any communication between the service you are authenticating to and the authenticator app. Two pieces of information is all it needs to generate the code you should use. You -- and the service you're authenticating to -- can generate codes without an internet or cell connection, as long as your clocks are in sync (for time based codes).
The app stores a secret seed number for each site's account, and this is used to generate the one-time-passwords. If they copied this seed number they could use it to authenticate as you, nevermind track you.
Just so we are clear: even with all the seeds/secret codes, Google (or anyone else) can't authenticate as you without your password. Hence, the name two-factor. It's just as important to keep the secret safe as it is to keep your password safe, but having only one isn't useful until you have the other.
posted by sbutler at 12:03 PM on September 6, 2013
The app stores a secret seed number for each site's account, and this is used to generate the one-time-passwords. If they copied this seed number they could use it to authenticate as you, nevermind track you.
Just so we are clear: even with all the seeds/secret codes, Google (or anyone else) can't authenticate as you without your password. Hence, the name two-factor. It's just as important to keep the secret safe as it is to keep your password safe, but having only one isn't useful until you have the other.
posted by sbutler at 12:03 PM on September 6, 2013
A potential alternative is Authy which has an app compatible with the standard TOTP protocol that Google Authenticator uses. It will consume the same codes/QR codes that GA does, and will let you manage multiple accounts.
It's gotten a little flack for a bluetooth feature it has which can potentially make it insecure (lets you authorize from your computer if it's paired with your phone), so I'd recommend disabling that feature (easy to do). Otherwise it's pretty solid.
posted by anateus at 2:45 PM on September 6, 2013
It's gotten a little flack for a bluetooth feature it has which can potentially make it insecure (lets you authorize from your computer if it's paired with your phone), so I'd recommend disabling that feature (easy to do). Otherwise it's pretty solid.
posted by anateus at 2:45 PM on September 6, 2013
Just to take this one step further, why would Google WANT your code? They can't do anything with it without your password and while I agree that Google certainly goes out of their way to gather information about you in order to market to you, are we really suggesting that "hacking into people's accounts" is one of the ways in which they do so?
posted by Inkoate at 6:58 PM on September 6, 2013
posted by Inkoate at 6:58 PM on September 6, 2013
Response by poster: Inkoate, you misunderstood me. I wasn't suggesting that Google would use my auth codes to somehow access my accounts. My question was simply whether Google central command would be keeping track of which accounts I have, when I authenticate them, etc. and adding that data to the rest of the model they have for me.
Google has made a great effort over the last couple of years to unify all of their services. They now have a single login, a single profile, all of their services know who you are and keep track of you in a unified way. I don't like Google trying to turn the Internet into their own version of Facebook. I find the company creepy and I no longer trust them. For that reason I try to avoid using Google services whenever possible.
My question was simply whether Google Authenticator was a Google (tm) Service (tm) (along the lines of "Login with your Facebook ID" or "Login with your Twitter ID" that has become so ubiquitous), or whether it was simply a specification for a peer-to-peer interaction. I wanted to know because it seemed strange that my company's webhost might want me to effectively "Sign in with Google" to double-auth changes I made to my account. I don't want Google involved in that process.
The responses I've gotten make it clear that Google Authenticator is a specification (plus some implementations) and not a service. That's a good thing, and makes me more willing to use it.
posted by alms at 9:33 PM on September 6, 2013
Google has made a great effort over the last couple of years to unify all of their services. They now have a single login, a single profile, all of their services know who you are and keep track of you in a unified way. I don't like Google trying to turn the Internet into their own version of Facebook. I find the company creepy and I no longer trust them. For that reason I try to avoid using Google services whenever possible.
My question was simply whether Google Authenticator was a Google (tm) Service (tm) (along the lines of "Login with your Facebook ID" or "Login with your Twitter ID" that has become so ubiquitous), or whether it was simply a specification for a peer-to-peer interaction. I wanted to know because it seemed strange that my company's webhost might want me to effectively "Sign in with Google" to double-auth changes I made to my account. I don't want Google involved in that process.
The responses I've gotten make it clear that Google Authenticator is a specification (plus some implementations) and not a service. That's a good thing, and makes me more willing to use it.
posted by alms at 9:33 PM on September 6, 2013
« Older Who is imagining this supergroup? | Costume suggestions: female character from a book. Newer »
This thread is closed to new comments.
Judging by Google's accidental deletion of all my seeds from their iPhone app a few days ago I think they officially only store them on the phone - otherwise they would have brought them back by now. They could be 'phoning home' with the data but this is risky for Google and unlikely - people tend to spot things like that. I don't know if it phones home with the other account info.
I'm more worried about it's reliability at the moment - the recent bug has locked me out of various accounts.
However, the protocol it uses is open and is available in other applications - you can use other OTP apps to log in. I've heard that Duo Mobile can also do Google Authenticator compatible codes, and the screenshot for it on iTunes shows it being used for Dropbox and Google. (I've not used it myself). I think there's even software that will work with a Yubikey to generate compatible codes.
posted by BinaryApe at 10:20 AM on September 6, 2013